JP7414052B2 - 走行支援システム、走行支援方法、走行支援制御プログラム - Google Patents

Description

本発明は、自動運転において、車両の走行に関わる自動運転サービス全般を支援するための走行支援システム、走行支援方法、走行支援制御プログラムに関する。なお、自動運転サービス全般とは、車両の走行に限らず、ドア開閉時の安全確認等を含むサービスである。以下では、車両走行に対する支援を主体に説明するため、走行支援と記載するが、当該走行支援には、上記自動運転サービス全般が含まれるものとする。

近年、自動車等の車両における自動運転に関する開発が進められている。特に、車載システムが車両の加速、操舵、制動の全てを自動的に行い、システムから要請があった場合にのみ運転手が手動で車両を運転する自動運転車両の開発が活発になっている。

さらに、このような自動運転車両の開発に伴い、自動運転中に運転に支障を来す事態が発生した場合に、遠隔で車両の安全な走行を確保するためのフェイルオペレーショナル技術の開発も進んでいる。

特許文献１には、自動運転車両の周囲または自動運転車両自体に何らかの異常が生じても、自動運転車両を適切に制御する技術が開示されている。

具体的には、監視オペレータにより確認した異常に対して走行指示を作成して、その走行指示を、異常に関連する自動運転車両へ通知すると共に、生じた異常による危険度と許容時間とに応じて優先度を設定し、優先度が高い異常に関連する自動運転車両から順に、自動運転車両へ送信した走行指示の内容を指示オペレータに通知し、走行指示内容の変更が必要と判断した場合に、変更後の走行指示を送信する構成となっている。

特開２０２０－１０２１５９号公報

しかしながら、特許文献１を含む先行技術では、最初に走行指示を行う端末装置（特許文献１では、監視オペレータが操作する監視用端末に相当）が、全ての自動運転車両からの情報処理（主として確認処理）に対応できていることが前提となっている。

言い換えれば、例えば、初動の走行指示が実行された後に優先度を設定し、初動の走行指示の変更要否を判断する特許文献１の技術では、自動運転車両からの情報数が、監視用端末による処理能力を超えると、初動の走行指示（異常の確認を含む）自体が遅延する可能性があり、自動運転に支障を来すことになる。

本発明は、複数の自動運転車両から異常を回避するための走行指示要請に対し、遅滞なく走行指示を行うことができる走行支援システム、走行支援方法、走行支援制御プログラムを得ることが目的である。

本発明に係る走行支援システムは、 自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する走行支援システムであって、前記支援要請を受けたとき、第１グループに属するオペレータの入力操作情報に基づいて、前記自動運転車両の走行に関する指示情報を提供する第１機能、及び、第２グループに属するオペレータの入力操作情報に基づいて、前記第１機能による前記支援要請の対応状況を含む前記第１グループに属するオペレータの稼働状況に関する情報を報知する第２機能の何れかで動作可能な複数の端末装置と、前記支援要請を受けた際、前記第１グループに属するオペレータに所定数の空きが有る閑散状態のとき前記支援要請の対応を前記第１グループに属するオペレータに割り当てる閑散時処理と、前記支援要請を受けた際、前記第１グループに属するオペレータに前記所定数の空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記第２グループに属するオペレータへの割り当てを検討する繁忙時処理と、の何れかを選択して実行する走行支援制御部と、を有している。

本発明に係る走行支援システムは、自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する指示情報を提供する走行支援システムであって、前記支援要請に対応して指示情報を各々が生成する複数の指示用端末装置と、前記指示用端末装置としての機能を備えると共に前記複数の指示用端末装置の動作状態を管理する管理用端末装置と、前記支援要請を受けた際、前記複数の指示用端末装置の中に空きが有る閑散状態の指示用端末装置が存在するとき前記自動運転車両から受ける複数の支援要請の各々の対応を閑散状態の指示用端末装置に割り当てる閑散時処理と、前記支援要請を受けた際、前記複数の指示用端末装置に空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記管理用端末装置への割り当てを検討する繁忙時処理と、が実行可能で、前記複数の指示用端末装置の動作状態に応じて、何れかの処理を選択して実行する走行支援制御部と、を有している。

本発明に係る走行支援方法は、自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する走行支援方法であって、前記支援要請を受けたとき、第１グループに属するオペレータの入力操作情報に基づいて、前記自動運転車両の走行に関する指示情報を提供する第１機能、及び、第２グループに属するオペレータの入力操作情報に基づいて、前記第１機能による前記支援要請の対応状況を含む前記第１グループに属するオペレータの稼働状況に関する情報を報知する第２機能の何れかで動作可能な複数の端末装置を備え、前記支援要請を受けた際、前記第１グループに属するオペレータに所定数の空きが有る閑散状態のとき前記支援要請の対応を前記第１グループに属するオペレータに割り当てる閑散時処理を実行し、前記支援要請を受けた際、前記第１グループに属するオペレータに前記所定数の空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記第２グループに属するオペレータへの割り当てを検討する繁忙時処理を実行する、ことを特徴としている。

本発明に係る走行支援方法は、自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する指示情報を提供する走行支援方法であって、前記支援要請に対応して指示情報を各々が生成する複数の指示用端末装置と、前記指示用端末装置としての機能を備えると共に前記複数の指示用端末装置の動作状態を管理する管理用端末装置と、を備え、前記支援要請を受けた際、前記複数の指示用端末装置の中に空きが有る閑散状態の指示用端末装置が存在するとき前記自動運転車両から受ける複数の支援要請の各々の対応を閑散状態の指示用端末装置に割り当てる閑散時処理を実行し、前記支援要請を受けた際、前記複数の指示用端末装置に空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記管理用端末装置への割り当てを検討する繁忙時処理を実行する、ことを特徴としている。

本発明に係る走行支援制御プログラムは、コンピュータを、上記の走行支援システムの前記走行支援制御部として動作させる、ことを特徴としている。

本発明によれば、複数の自動運転車両から異常を回避するための走行指示が要請に対し、遅滞なく走行指示を行うことができる。

第１の実施の形態に係る車両の自動運転における走行を支援する走行支援制御部を含む走行支援システムの概略図である。 第１の実施の形態に係る自動運転制御装置と走行支援システムとの間で実行される支援要請に基づく情報の送受信制御を実行するための機能ブロック図である。 第１の実施の形態に係る走行支援システムに設置されるオペレーション制御部の概略図である。 第１の実施の形態に係る走行支援システムにおけるデータベースの詳細であり、（Ａ）はオペレータ稼働状況データベース、（Ｂ）は支援発生予測用データベース、（Ｃ）は支援ログデータベースに格納された情報の模式図である。 第１の実施の形態に係る自動運転制御装置側走行支援要請制御ルーチンを示すフローチャートである。 第１の実施の形態に係る走行支援システム側走行支援制御ルーチンを示すフローチャートである。 第１の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第２の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第３の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第４の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第５の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第６の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第７の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第８の実施の形態に係る繁忙時のオペレータ割当サブルーチンを示す制御フローチャートである（図６のステップ１７６）。 第９の実施の形態に係る自動運転制御装置と走行支援システムとの間で実行される支援要請に基づく情報の送受信制御を実行するための機能ブロック図である。 第９の実施の形態に係る走行支援システム側走行支援制御ルーチンを示すフローチャートである。

［第１の実施の形態］

図１には、第１の実施の形態に係る走行支援システム１０による、車両１２の自動運転中の走行支援を実行するためのネットワーク図である。

車両１２には、車両制御装置１４及び自動運転制御装置２０が搭載されている。自動運転制御装置２０は、自動運転制御を主体とし、走行支援に必要な情報源としても機能する。

車両制御装置１４は、車両１２が走行しているときの駆動系統（エンジン制御等）及び電気系統（各部の状態検出センサによる故障診断等）を含む制御を実行する。

車両制御装置１４には、車両１２の周囲を撮影するカメラ群（図１では、一例として、前方向カメラ１６Ａ、左前方向カメラ１６Ｂ、左後方向カメラ１６Ｃ、右前方向カメラ１６Ｄ、右後方向カメラ１６Ｅ、及び後方向カメラ１６Ｆを図示）が接続されている（総称する場合、「カメラ群１６」という）。また、車両制御装置１４には、複数のミリ波レーダ及びＬＩＤＡＲを備えたレーダ群１８が接続されている。

自動運転制御装置２０は、車両制御装置１４から自動運転に必要な情報（例えば、上記カメラ群１６及びレーダ群１８からの検出情報）に基づき、目的地への運転操作を確定し、車両制御装置１４へ指示する。

自動運転制御装置２０は、ネットワーク２２の無線通信装置２２Ａを介して、走行支援システム１０と通信可能となっている。

走行支援システム１０では、各車両１２からの自動運転による走行履歴情報が集約される。走行支援システム１０は、図２に示される如く、複数の端末装置が、指示用端末装置としての指示オペレータ端末４０と、管理用端末装置としての管理オペレータ端末４１とに分類されて配置されている。走行支援システム１０では、指示オペレータ端末４０（又は管理オペレータ端末４１）により走行支援の指示を行うようになっている。なお、ネットワーク２２には、インフラ管理システム２４が接続されている。

図２は、自動運転制御装置２０と走行支援システム１０との間で実行される支援要請に基づく情報（情報源として、インフラ管理システム２４を含む）の送受信制御を実行するための機能ブロック図である。なお、この機能ブロック図は一例であり、本発明の目的を達成するものであれば、機能の種類や組み合わせは限定されるものではない。また、図２に示す一部又は全部の機能は、マイクロコンピュータ等によるプログラムの実行によるソフトウェア処理であってもよい。

（インフラ管理システム２４）
図２に示される如く、インフラ管理システム２４には、インフラ側通信部２４Ｂが設けられている。走行支援システム１０では、インフラ管理システム２４の情報管理部２４Ａの情報（リアルタイムの交通情報、情報取得時の時刻情報及び天候情報等）が必要に応じて取得可能である。

（自動運転制御装置２０）
図２に示される如く、自動運転制御装置２０は、検出情報格納部３０を備えており、検出情報格納部３０には、車両制御装置１４を介して、カメラ群１６及びレーダ群１８の検出情報、及びダイアグコード（ＣＡＮ（Controller Area Network）信号）が入力され、格納されるようになっている。また、検出情報格納部３０は、走行制御部３２に接続され、必要な検出情報が、走行制御情報として走行制御部３２へ送出される。

走行制御部３２では、走行計画に基づいて自動運転を制御すると共に、車両側通信部３６を介して、走行支援システム１０との間で、走行支援要請を通知し、かつ、走行支援要請に対する走行支援情報を取得する。

すなわち、走行制御部３２には、支援要否判定部３４が接続されており、自動運転状況に基づき、走行支援システム１０に対して走行支援を要請するか否かを判定する。

この走行支援が必要と判定された場合、走行制御部３２では、車両側通信部３６を介して、走行支援システム１０に対して、走行支援を通知する。

（走行支援システム１０）
走行支援システム１０は、所謂自動運転センタにおいて、オペレータ（後述する指示オペレータＯＰ、管理オペレータＯＰ）による運用に必要な制御システムであり、走行支援制御部１０Ａと、オペレーション制御部１０Ｂと、センタ側通信部１０Ｃを備えている。

センタ側通信部１０Ｃでは、各車両１２に設けられた車両側通信部３６、及びインフラ管理システム２４に設けられたインフラ側通信部２４Ｂを介して、各種情報の授受が実行される。当該情報は、走行支援制御部１０Ａの支援制御部５２によって処理される。

ここで、車両１２が自動運転による走行中、自動運転に支障を来す事態（事象）が発生した場合に、走行支援システム１０へ支援要請を通知すると、走行支援システム１０は、車両１２を監視している指示オペレータ端末４０又は管理オペレータ端末４１から適切な走行支援を受けることで、自動運転に支障を来す事態に対して、走行を継続することが可能となる。

図３に示される如く、オペレーション制御部１０Ｂは、全体監視モニタ３９、指示オペレータ端末４０、及び管理オペレータ端末４１を備えている。

全体監視モニタ３９には、表示画面が分割されて、複数の支援要請関連画像が表示される。

指示オペレータ端末４０及び管理オペレータ端末４１は、それぞれ入力デバイス（キーボード、マウス等）４０Ａ、４１Ａ、及び、出力デバイス（モニタ、プリンタ等）４０Ｂ、４１Ｂを備えている。

指示オペレータ端末４０及び管理オペレータ端末４１には、それぞれオペレータ（指示オペレータＯＰ、管理オペレータＯＰ）が対峙しており、出力デバイス４０Ｂ、４１Ｂからの情報に基づき、入力デバイス４０Ａ、４１Ａから走行支援に関する情報を入力する。

ここで、第１の実施の形態では、指示オペレータ端末４０は、第１グループに属するオペレータ（指示オペレータＯＰ）が担当し、車両１２から通知される各支援要請のそれぞれに対応することを主たる機能（第１機能）とする。第１機能は、オペレータの入力操作情報に基づき、支援要請に対応して、指示情報を生成する。

一方、管理オペレータ端末４１は、第２グループに属するオペレータ（管理オペレータＯＰ）が担当し、後述するオペレータ稼働状況データベース５４にアクセスして、複数の指示オペレータ端末４０（指示オペレータＯＰ）の稼働状況に関する情報を報知することを主たる機能（第２機能）とする。なお、管理オペレータ端末４１は、必要に応じて、第１機能として動作することが可能となっている。

通常は、１台の管理オペレータ端末４１（１）に対して複数台の指示オペレータ端末４０（１）～４０（ｎ）が１つのグループとなり、複数のグループに分類される（ｎは、指示オペレータ端末４０の台数）。なお、図３では、１つのグループを図示している。

オペレータは、それぞれ予め定めた所定基準により、第１グループ又は第２グループに分類されており、操作し得る機能が決まっている。言い換えれば、オペレータが端末装置に対峙することで、当該端末装置の機能が決定する。

以下、表１に、端末装置における、機能（及び機能の説明）と動作中の設定（名称）との関係を示す。

第２の機能における、「指示用端末装置及び指示オペレータの稼働状況に関する情報を報知する」について、詳細に説明する。

報知とは、指示オペレータ端末４０を担当するオペレータの仕事の確認、各オペレータが走行支援サービスとして問題なく対応できているかを監視し、稼働状況に関する情報として報知することを指す。より具体的には、以下のような監視項目を有する。
（監視項目１） 指示オペレータの状態
（監視項目２） 走行支援サービスを行うためのシステム全体としての機器等の異常の有無の確認
（監視項目３） オペレータのシフト管理
（監視項目４） 支援要請対象となる車両１２の運行計画の管理
管理オペレータＯＰは、第２機能を用いて、上記監視項目の監視結果から、指示オペレータ端末４０及び指示オペレータＯＰの稼働状況に関する情報を報知する。

なお、上記監視項目のそれぞれは必須ではなく、必要に応じて選択すればよい。また、上記監視項目に限定されるものではない。

以下の第１の実施の形態（第２の実施の形態から第８の実施の形態を含む）では、図３に示すように、事前に、端末装置にオペレータが対峙し、指示オペレータ端末４０と、管理オペレータ端末４１とに分類し、当該指示オペレータ端末４０と、管理オペレータ端末４１とを主体とした走行支援制御として説明する。オペレータを主体とした走行支援制御については、第９の実施の形態で詳細に説明する（図１４及び図１５参照）。

図２に示される如く、センタ側通信部１０Ｃでは、車両側通信部３６を介して、自動走行に関する情報を取得し、支援制御部５２へ送出する。また、センタ側通信部１０Ｃでは、インフラ側通信部２４Ｂを介して、情報管理部２４Ａの情報（リアルタイムの交通情報、情報取得時の時刻情報及び天候情報等）を取得し、支援制御部５２へ送出する。

支援制御部５２では、支援要請受信機能５２Ａ、支援内容判定機能５２Ｂ、優先度設定機能５２Ｃ、オペレータ割当機能５２Ｄ、及び支援発生予測機能５２Ｅを備えている。

支援要請受信機能５２Ａでは、車両１２から通知された支援要請を受信することはもちろん、支援要請と共に通知される情報に基づき、車両１２の状況を解析する。

支援内容判定機能５２Ｂでは、支援要請受信機能５２Ａの解析結果に基づき、支援内容のカテゴリー（例えば、発車支障、安全確認、事故発生、及び不明等）を判定する。

優先度設定機能５２Ｃでは、支援内容に基づいて、支援する優先度を設定する。例えば、優先度を定量化して、優先度が最も低いレベル（レベル１）から、優先度が最も高いレベル（レベル１０）を設定し、レベル１～１０の間で振り分けて設定する（レベルの段数は限定されない。）。なお、支援内容によっては、優先度が設定できない場合があり、その場合は、管理オペレータ端末４１（管理オペレータＯＰによる操作）によって設定する場合もある。

オペレータ割当機能５２Ｄでは、現在の指示オペレータ端末４０及び管理オペレータ端末４１の稼働状況に関する情報に基づき、支援要請を割り当てる機能を有する。

言い換えれば、指示オペレータ端末４０及び管理オペレータ端末４１には、それぞれ１：１で指示オペレータＯＰと管理オペレータＯＰが対峙し、操作しているため、当該指示オペレータＯＰと管理オペレータＯＰに対する支援要請の割り当てを実行する。

支援発生予測機能５２Ｅでは、過去の支援要請履歴等のビッグデータを用いて、例えば、ＡＩによる機械学習を実行し、将来の支援発生を予測するための解析を実行する。

支援制御部５２には、オペレータ稼働状況データベース５４、支援発生予測用ビッグデータベース５６、及び、支援ログデータベース５８が接続されており、支援制御部５２で実行する各機能は、それぞれのデータベースとの間で、必要な情報の授受が行われるようになっている。

図４は、オペレータ稼働状況データベース５４、支援発生予測用ビッグデータベース５６、及び、支援ログデータベース５８に格納される情報例について説明する。

（オペレータ稼働状況データベース５４）

図４（Ａ）に示される如く、オペレータ稼働状況データベース５４には、オペレータＩＤ（対峙する指示オペレータ端末４０、管理オペレータ端末４１の特定に相当）毎の、オペレータ種（指示又は管理）、及び状況（待機中、対応中)が格納されている。情報内容は、支援制御部５２とのやりとりで、常に更新される。

図４（Ｂ）に示される如く、支援発生予測用ビッグデータベース５６には、車両位置情報群、走行ルート情報群、交通量情報群、天候情報群、支援情報群、及び支援対応時間情報群がそれぞれビッグデータとして格納される。格納される情報は、支援制御部５２とのやりとりで、常に蓄積される。

図４（Ｃ）に示される如く、支援ログデータベース５８には、発生時刻毎に、支援内容、優先度、対応オペレータＩＤ（対峙する指示オペレータ端末４０、管理オペレータ端末４１の特定に相当）、対応経過時間、対応目標時間、及び予測対応残り時間が格納されている。情報内容は、支援制御部５２とのやりとりで、常に蓄積される。

ここで、オペレータ割当機能５２Ｄにおいて、定常状態は、車両１２から走行支援要請があると、待機中の指示オペレータ端末４０を検索して、割り当てる。定常状態とは、例えば、過去の履歴等により予測された車両１２の走行支援要請数の範囲内であれば、指示オペレータ端末４０によって対応可能な状態である（閑散時）。

一方、自動運転中の車両１２の運行状況、天候、時間帯等により、走行支援要請数が、指示オペレータ端末４０を上回る場合も想定される。この場合は、走行支援システム１０側で受け付けた順に、待ち行列にセットすることになる（順番待ち）。

しかしながら、受け付けた順に順番待ちにすると、優先度の高い（迅速に走行支援がほしい）ものであっても、待機時間が必要となる。以下、この状況を、定常状態における「繁忙時」という。

そこで、第１の実施の形態では、繁忙時の状況となった場合に、支援要請が予め定めた優先度よりも高い優先度（高優先度）を条件として、通常は、指示オペレータ端末４０の稼働状況を管理する立場である、管理オペレータ端末４１に対して、支援要請の対応を指示するようにした。

高優先度か否かのしきい値レベルは、特に限定されないが、例えば、前述のレベル１～レベル１０(図４（Ｃ）参照)の設定で言えば、レベル８以上を基準とし、繁忙時となる頻度に応じて、しきい値レベルを調整してもよい。

以下に、第１の実施の形態の作用を図５～図７のフローチャートに従い説明する。

（走行支援要請)
図５は、自動運転制御装置２０側で実行される自動運転制御ルーチンのサブルーチンであり、走行支援要請制御ルーチンを示すフローチャートである。

ステップ１００では、走行支援システム１０へ、走行支援を要請する。この走行支援の要請は、車両側通信部３６を介して、走行支援システム１０のセンタ側通信部１０Ｃへ送出される。

次のステップ１０２では、走行支援システム１０から走行支援情報を取得したか否かを判断する。

このステップ１０２で肯定判定された場合は、走行支援要請に対する応答があったと判断し、ステップ１０４へ移行して、取得した走行支援情報に基づいて、走行を制御し、このルーチンは終了する。

一方、ステップ１０２で否定判定された場合は、ステップ１０６へ移行して、所定時間経過したか否かを判断する。このステップ１０６で否定判定された場合は、ステップ１０２へ戻る。また、ステップ１０６で肯定判定された場合は、ステップ１０８へ移行する。

ステップ１０８では、走行支援要請に対する応答がないと判断し、異常処理（例えば、停車処理等）を実行し、このルーチンは終了する。

（走行支援制御）
図６は、走行支援システム側で実行される、走行支援制御ルーチンを示すフローチャートである。

ステップ１５０では、車両１２の自動運転制御装置２０から支援要請があったか否かを判断し、肯定判定されるまで、待機する。

ステップ１５０で肯定判定されると、ステップ１５２へ移行して支援内容の確認を実行すること共に、優先度の自動設定を実行する。

優先度の自動設定は、実行可能な場合と不可能な場合がある。そこで、ステップ１５４では、優先度の自動設定の成否を確認し、ステップ１５６へ移行する。

ステップ１５６では、指示オペレータ端末４０の空き状況を取得し、ステップ１５８へ移行する。

ステップ１５８では、待機中の指示オペレータ端末４０があるか否かを判断する。

ステップ１５８で肯定判定、すなわち、待機中の指示オペレータ端末４０があると判定された場合は、ステップ１６０へ移行して、待機中の指示オペレータ端末４０へ、支援要請の対応を指示し、ステップ１６２へ移行する。

ステップ１６２では、ステップ１５４で確認した優先度の自動設定の成否を判断し、成功している場合は、このルーチンは終了する。

また、優先度の自動設定が失敗している場合は、ステップ１６４へ移行して、優先度の設定を、以下の（１）または（２）の手段で実行し、このルーチンは終了する。

（１） 管理オペレータ端末４１が空き次第、手動設定

（２） 指示オペレータ端末４０の支援状況に基づき、システムにより自動設定

ここで、ステップ１５８において否定判定、すなわち、待機中の指示オペレータ端末４０がないと判定された場合は、ステップ１６６へ移行する。

ステップ１６６では、優先度は設定済か否かを判断し、否定判定された場合は、ステップ１６８へ移行して待機中の管理オペレータ端末４１があるか否かを判断する。

このステップ１６８で肯定判定されると、ステップ１７０へ移行して、支援内容の確認を指示すると共に、優先度の手動設定を指示し、ステップ１７２へ移行する。

また、ステップ１６６で肯定判定（優先度設定済）された場合は、ステップ１７２へ移行する。

ステップ１７２では、待機中の管理オペレータ端末４１があるか否かを再度判断し、否定判定された場合は、ステップ１７４へ移行する。また、ステップ１６８で否定判定された場合も、ステップ１７４へ移行する。

ステップ１７４では、支援要請対象を待ち行列へセットし、このルーチンは終了する。すなわち、ステップ１７４に到達した場合は、オペレータ端末への割り当ては無いことになる。

一方、ステップ１７２で肯定判定された場合は、待機中の管理オペレータ端末４１があると判定され、ステップ１７６へ移行する。

ステップ１７６では、繁忙時、すなわち、少なくとも待機中の指示オペレータ端末４０が存在しない状態での、オペレータ端末への割当処理を実行する（詳細は、図７参照）。

図７は、第１の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図７に示される如く、ステップ１８０では、支援要請は高優先度か否かを判断する。高優先度とは、一例としては、図４（Ｃ）に示すレベル１～レベル１０の設定の中のレベル８以上とする。

ステップ１８０で否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ１８２へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ１８０で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ１８４へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。

［第２の実施の形態］
以下に、本発明の第２の実施の形態について説明する。なお、第２の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第２の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、次の支援発生までの予測時間と、その優先度を予測して（情報αを得て）、割り当てを実行することにある。

図８は、第２の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図８に示される如く、ステップ２００では、次の支援発生までの予測時間Ｘと、その優先度を予測する。この予測情報を情報αとする。

次のステップ２０２では、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する確率Ｒｘを計算する。

次のステップ２０４では、確率しきい値Ｒｙを読み出し、ステップ２０６へ移行し、確率Ｒｘと確率しきい値Ｒｙとを比較する（Ｒｘ≧Ｒｙ？）。

このステップ２０６で否定判定（Ｒｘ＜Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が低いと判断し、ステップ２０８へ移行して、待機中の管理オペレータ端末４１に対して、支援要請に対する対応を指示して、このルーチンは終了する。

一方、ステップ２０６で肯定判定（Ｒｘ≧Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が高いと判断し、ステップ２１０へ移行して、支援要請は高優先度が否かを判断する。

ステップ２１０で、否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ２１２へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ２１０で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ２１４へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、次いで、ステップ２１６へ移行して、オペレータ端末の増設を指示し、このルーチンは終了する。

［第３の実施の形態］
以下に、本発明の第３の実施の形態について説明する。なお、第３の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第３の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、現在対応中の、全ての支援の優先度を取得して（情報βを得て）、割り当てを実行することにある。

図９は、第３の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図９に示される如く、ステップ２２０では、現在対応中の、全ての支援の優先度を取得する。この取得情報を情報βとする。

次のステップ２２２では、優先度が所定のしきい値以下の支援に対応している指示オペレータ端末４０を検索する。

次のステップ２２４では、ステップ２２２の検索の結果、該当する指示オペレータ端末４０があるか否かを判断する。

このステップ２２４で肯定判定された場合は、ステップ２２６へ移行して、該当する指示オペレータ端末４０に対して、現在対応中の支援要請よりも優先して、今回の支援要請に対する対応を指示して、このルーチンは終了する。すなわち、指示オペレータ端末４０の現在進行中の案件（例えば、極めて優先度が低い案件）を一旦保留して、今回の案件に対応させる。

一方、ステップ２２４で否定判定された場合は、ステップ２２８へ移行して、支援要請は高優先度が否かを判断する。

ステップ２２８で、否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ２３０へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ２２８で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ２３２へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。

［第４の実施の形態］
以下に、本発明の第４の実施の形態について説明する。なお、第４の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第４の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、現在対応中の、各々の支援終了までの予測時間を取得して（情報γを得て）、割り当てを実行することにある。

図１０は、第４の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図１０に示される如く、ステップ２４０では、現在対応中の、各々の支援終了までの予測時間ｔｘを取得する。この取得した予測情報を情報γとする。

次のステップ２４２では、支援終了予測時間しきい値ｔｙを読み出し、次いでステップ２４４へ移行して、予測時間ｔｘと予測時間しきい値ｔｙとを比較する（ｔｘ≦ｔｙ？）。

このステップ２４４で否定判定（ｔｘ＞ｔｙ）された場合は、現在対応中の支援がなかなか終わりそうにない状況であると判断し、ステップ２４６へ移行する。

また、ステップ２４４で肯定判定（ｔｘ≦ｔｙ）された場合は、もうすぐ空きそうなオペレータがいる、つまりそれまでの待ち時間を許容できると判断し、ステップ２４７へ移行して、所定条件の下で、支援要請対象を待ち行列へセットし、このルーチンは終了する。なお、所定条件の下とは、予測時間ｔｘと予測時間しきい値ｔｙとの乖離状況によって、順番を入れ替える場合もあることを意味する。例えば、予測時間ｔｘと予測時間しきい値ｔｙとの乖離が僅かな場合は、早めに順番がくるように調整する。なお、予測時間しきい値ｔｙは、支援要請の内容によって支援毎に設定されている。これにより、予測時間ｔｘと予測時間しきい値ｔｙとの差が、所定の基準を境に、大きい場合と小さい場合とが起こり得る。ここで、予測時間ｔｘと予測時間しきい値ｔｙとの差が小さい場合、つまり、許容できる待ち時間ぎりぎりの場合は、予測時間ｔｘと予測時間しきい値ｔｙとの差が大きい支援（待ち行列にセット済）よりも優先する。

ステップ２４６では、支援要請は高優先度が否かを判断する。このステップ２４６で否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ２４８へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ２４６で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ２５０へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。すなわち、指示オペレータＯＰが対応中の支援要請の優先度は考慮せず、「すぐに空きそうかどうか」、「あがってきた支援要請が高優先度かどうか」で、指示オペレータが空かなそう、かつ上がってきた支援要請が高優先度であれば、管理オペレータが対応する。

［第５の実施の形態］
以下に、本発明の第５の実施の形態について説明する。なお、第５の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第５の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、次の支援発生までの予測時間と、その優先度を予測して（情報αを得て）、かつ、現在対応中の、全ての支援の優先度を取得して（情報βを得て）、割り当てを実行することにある。

図１１は、第５の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図１１に示される如く、ステップ２６０では、次の支援発生までの予測時間Ｘと、その優先度を予測する。この予測情報を情報αとする。

次のステップ２６２では、現在対応中の、全ての支援の優先度を取得する。この取得情報を情報βとする。

次のステップ２６４では、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する確率Ｒｘを計算する。

次のステップ２６６では、確率しきい値Ｒｙを読み出し、ステップ２６８へ移行し、確率Ｒｘと確率しきい値Ｒｙとを比較する（Ｒｘ≧Ｒｙ？）。

このステップ２６８で否定判定（Ｒｘ＜Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が低いと判断し、ステップ２７０へ移行して、待機中の管理オペレータ端末４１に対して、支援要請に対する対応を指示して、このルーチンは終了する。

一方、ステップ２６８で肯定判定（Ｒｘ≧Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が高いと判断し、ステップ２７２へ移行する。

ステップ２７２では、優先度が所定のしきい値以下の支援に対応している指示オペレータ端末４０を検索する。

次のステップ２７４では、ステップ２７２の検索の結果、該当する指示オペレータ端末４０があるか否かを判断する。

このステップ２７４で肯定判定された場合は、ステップ２７６へ移行して、該当する指示オペレータ端末４０に対して、現在対応中の支援要請よりも優先して、今回の支援要請に対する対応を指示して、このルーチンは終了する。

一方、ステップ２７４で否定判定された場合は、ステップ２７８へ移行して、支援要請は高優先度が否かを判断する。

ステップ２７８で、否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ２８０へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ２７８で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ２８２へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。

［第６の実施の形態］
以下に、本発明の第６の実施の形態について説明する。なお、第６の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第６の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、次の支援発生までの予測時間と、その優先度を予測して（情報αを得て）、かつ、現在対応中の、各々の支援終了までの予測時間を取得して（情報γを得て）、割り当てを実行することにある。

図１２は、第６の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図１２に示される如く、ステップ２８０では、次の支援発生までの予測時間Ｘと、その優先度を予測する。この予測情報を情報αとする。

次のステップ２８２では、現在対応中の、各々の支援終了までの予測時間ｔｘを取得する。この取得した予測情報を情報γとする。

次のステップ２８４では、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する確率Ｒｘを計算する。

次のステップ２８６では、確率しきい値Ｒｙを読み出し、ステップ２８８へ移行し、確率Ｒｘと確率しきい値Ｒｙとを比較する（Ｒｘ≧Ｒｙ？）。

このステップ２８８で否定判定（Ｒｘ＜Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が低いと判断し、ステップ２９０へ移行して、待機中の管理オペレータ端末４１に対して、支援要請に対する対応を指示して、このルーチンは終了する。

一方、ステップ２８８で肯定判定（Ｒｘ≧Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が高いと判断し、ステップ２９２へ移行する。

ステップ２９２では、支援終了予測時間しきい値ｔｙを読み出し、次いでステップ２９４へ移行して、予測時間ｔｘと予測時間しきい値ｔｙとを比較する（ｔｘ≦ｔｙ？）。

このステップ２９４で否定判定（ｔｘ＞ｔｙ）された場合は、現在対応中の支援がなかなか終わりそうにない状況であると判断し、ステップ２９６へ移行する。

また、ステップ２９４で肯定判定（ｔｘ≦ｔｙ）された場合は、もうすぐ空きそうなオペレータがいる、つまりそれまでの待ち時間を許容できると判断し、ステップ２９８へ移行して、所定条件の下で、支援要請対象を待ち行列へセットし、このルーチンは終了する。なお、所定条件の下とは、予測時間ｔｘと予測時間しきい値ｔｙとの乖離状況によって、順番を入れ替える場合もあることを意味する。例えば、予測時間ｔｘと予測時間しきい値ｔｙとの乖離が僅かな場合は、早めに順番がくるように調整する。

ステップ２９６では、支援要請は高優先度が否かを判断する。このステップ２９６で否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ３００へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ２９６で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ３０２へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。

［第７の実施の形態］
以下に、本発明の第７の実施の形態について説明する。なお、第７の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第７の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、現在対応中の、全ての支援の優先度を取得して（情報βを得て）、かつ、現在対応中の、各々の支援終了までの予測時間を取得して（情報γを得て）、割り当てを実行することにある。

図１３は、第７の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図１３に示される如く、ステップ３２０では、現在対応中の、全ての支援の優先度を取得する。この取得情報を情報βとする。

次のステップ３２２では、現在対応中の、各々の支援終了までの予測時間ｔｘを取得する。この取得した予測情報を情報γとする。

次のステップ３２４では、優先度が所定のしきい値以下の支援に対応している指示オペレータ端末４０を検索する。

次のステップ３２６では、ステップ３２４の検索の結果、該当する指示オペレータ端末４０があるか否かを判断する。

ステップ３２６で否定判定された場合は、ステップ３２８へ移行して、支援要請は高優先度が否かを判断する。

ステップ３２８で、否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ３３０へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ３２８で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ３３２へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、このルーチンは終了する。

一方、ステップ３２６で肯定判定された場合は、ステップ３３４へ移行して、該当端末の支援終了予測時間しきい値ｔｙを読み出し、次いでステップ３３６へ移行して、予測時間ｔｘと予測時間しきい値ｔｙとを比較する（ｔｘ≦ｔｙ？）。

このステップ３３６で否定判定（ｔｘ＞ｔｙ）された場合は、現在対応中の支援がなかなか終わりそうにない状況であると判断し、ステップ３３８へ移行する。

また、ステップ３３６で肯定判定（ｔｘ≦ｔｙ）された場合は、もうすぐ空きそうなオペレータがいる、つまりそれまでの待ち時間を許容できると判断し、ステップ３４０へ移行して、所定条件の下で、支援要請対象を待ち行列へセットし、このルーチンは終了する。なお、所定条件の下とは、予測時間ｔｘと予測時間しきい値ｔｙとの乖離状況によって、順番を入れ替える場合もあることを意味する。例えば、予測時間ｔｘと予測時間しきい値ｔｙとの乖離が僅かな場合は、早めに順番がくるように調整する。なお、予測時間しきい値ｔｙは、支援要請の内容によって支援毎に設定されている。これにより、予測時間ｔｘと予測時間しきい値ｔｙとの差が、所定の基準を境に、大きい場合と小さい場合とが起こり得る。ここで、予測時間ｔｘと予測時間しきい値ｔｙとの差が小さい場合、つまり、許容できる待ち時間ぎりぎりの場合は、予測時間ｔｘと予測時間しきい値ｔｙとの差が大きい支援（待ち行列にセット済）よりも優先する。

ステップ３３８では、支援要請は高優先度が否かを判断する。このステップ３３８で否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ３４２へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ３３８で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ３４４へ移行して、ステップ３２４で検索された指示オペレータ端末４０に対して、現在対応中の支援要請よりも優先して、今回の支援要請に対する対応を指示して、このルーチンは終了する。例えば、管理オペレータ端末４１にはできるだけ割り当てたくないので、所定のしきい値以下の支援に対応している指示オペレータ端末４０が存在するのであれば、指示オペレータ端末４０に割り当てる。なお、ステップ３４４において、指示オペレータ端末４０が現在対応している優先度が、今回の優先度よりも低い場合、指示オペレータ端末４０に対応を指示し、拒否された場合に、管理オペレータ端末４１に対応を指示するといった、段階的な処理を実行してもよい。

［第８の実施の形態］
以下に、本発明の第８の実施の形態について説明する。なお、第８の実施の形態において、第１の実施の形態と同一構成については、同一の符号を付して、その構成の説明を省略する。

第８の実施の形態の特徴は、図６のステップ１７６における繁忙時のオペレータ割当処理において、次の支援発生までの予測時間と、その優先度を予測して（情報αを得て）、かつ、現在対応中の、全ての支援の優先度を取得して（情報βを得て）、かつ、現在対応中の、各々の支援終了までの予測時間を取得して（情報γを得て）、割り当てを実行することにある。

図１４は、第８の実施の形態における繁忙時のオペレータ割当処理制御ルーチンを示すフローチャートである。

図１４に示される如く、ステップ３５０では、次の支援発生までの予測時間Ｘと、その優先度を予測する。この予測情報を情報αとする。

次のステップ３５２では、現在対応中の、全ての支援の優先度を取得する。この取得情報を情報βとする。

次のステップ３５４では、現在対応中の、各々の支援終了までの予測時間ｔｘを取得する。この取得した予測情報を情報γとする。

次のステップ３５６では、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する確率Ｒｘを計算する。

次のステップ３５８では、確率しきい値Ｒｙを読み出し、ステップ３６０へ移行し、確率Ｒｘと確率しきい値Ｒｙとを比較する（Ｒｘ≧Ｒｙ？）。

このステップ３６０で否定判定（Ｒｘ＜Ｒｙ）された場合は、予測時間Ｘ以内に待機中の管理オペレータ端末４１の数以上の高優先度（または支援内容不明）の支援が発生する可能性が低いと判断し、ステップ３６２へ移行して、待機中の管理オペレータ端末４１に対して、支援要請に対する対応を指示して、このルーチンは終了する。

一方、ステップ３６０で肯定判定（Ｒｘ≧Ｒｙ）された場合は、ステップ３６４へ移行する。

ステップ３６４では、優先度が所定のしきい値以下の支援に対応している指示オペレータ端末４０を検索する。

次のステップ３６６では、ステップ３６４の検索の結果、該当する指示オペレータ端末４０があるか否かを判断する。

ステップ３６６で否定判定された場合は、ステップ３６８へ移行して、支援要請は高優先度が否かを判断する。

ステップ３６８で、否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ３７０へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ３６８で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ３７２へ移行して、待機中の管理オペレータ端末４１に、支援要請に対する対応を指示し、ステップ３７４へ移行して、オペレータ端末の増設を指示し、このルーチンは終了する。

一方、ステップ３６６で肯定判定された場合は、ステップ３７６へ移行して、該当端末の支援終了予測時間しきい値ｔｙを読み出し、次いでステップ３７８へ移行して、予測時間ｔｘと予測時間しきい値ｔｙとを比較する（ｔｘ≦ｔｙ？）。

このステップ３７８で否定判定（ｔｘ＞ｔｙ）された場合は、現在対応中の支援がなかなか終わりそうにない状況であると判断し、ステップ３８０へ移行する。

また、ステップ３７８で肯定判定（ｔｘ≦ｔｙ）された場合は、もうすぐ空きそうなオペレータがいる、つまりそれまでの待ち時間を許容できると判断し、ステップ３８２へ移行して、所定条件の下で、支援要請対象を待ち行列へセットし、このルーチンは終了する。なお、所定条件の下とは、予測時間ｔｘと予測時間しきい値ｔｙとの乖離状況によって、順番を入れ替える場合もあることを意味する。例えば、予測時間ｔｘと予測時間しきい値ｔｙとの乖離が僅かな場合は、早めに順番がくるように調整する。なお、予測時間しきい値ｔｙは、支援要請の内容によって支援毎に設定されている。これにより、予測時間ｔｘと予測時間しきい値ｔｙとの差が、所定の基準を境に、大きい場合と小さい場合とが起こり得る。ここで、予測時間ｔｘと予測時間しきい値ｔｙとの差が小さい場合、つまり、許容できる待ち時間ぎりぎりの場合は、予測時間ｔｘと予測時間しきい値ｔｙとの差が大きい支援（待ち行列にセット済）よりも優先する。

ステップ３８０では、支援要請は高優先度が否かを判断する。このステップ３８０で否定判定された場合は、比較的急を要する支援要請ではないと判断し、ステップ３８４へ移行して、支援要請対象を待ち行列へセットし、このルーチンは終了する。

また、ステップ３８０で肯定判定された場合は、比較的急を要する支援要請であると判断し、ステップ３８６へ移行して、ステップ３６４で検索された指示オペレータ端末４０に対して、現在対応中の支援要請よりも優先して、今回の支援要請に対する対応を指示して、このルーチンは終了する。例えば、管理オペレータ端末４１にはできるだけ割り当てたくないので、所定のしきい値以下の支援に対応している指示オペレータ端末４０が存在するのであれば、指示オペレータ端末４０に割り当てる。なお、ステップ３８６において、指示オペレータ端末４０が現在対応している優先度が、今回の優先度よりも低い場合、指示オペレータ端末４０に対応を指示し、拒否された場合に、管理オペレータ端末４１に対応を指示するといった、段階的な処理を実行してもよい。

以上説明したように本実施の形態では、オペレータ割当機能５２Ｄ（図２参照）において、車両１２から走行支援要請があると、待機中の指示オペレータ端末４０を検索して、割り当て、車両１２の運行状況、天候、時間帯等により、走行支援要請数が、指示オペレータ端末４０を上回る場合は、待ち行列にセットすることを定常状態とし、繁忙時の状況となった場合に、高優先度を条件として、通常は、指示オペレータ端末４０の稼働状況に関する情報を管理する立場である、管理オペレータ端末４１に対して、支援要請の対応を指示するようにし、さらに、情報α、情報β及び情報γを組み合わせることで、より、待ち行列にセットする支援要請数を軽減することができる。

以下、表２に、基本情報（管理オペレータ端末４１の利用）によって、待ち行列にセットする支援要請数を軽減することに加え（第１の実施の形態）、情報α、情報β、及び情報γの組み合わせにより相乗効果をもたらす第２の実施の形態から第８の実施の形態における、それぞれの作用及び効果を示す。

（第９の実施の形態）
第１の実施の形態（及び第１の実施の形態の構成を流用する第２の実施の形態から第８の実施の形態）では、予め、端末装置とオペレータとをペアとして説明した（指示オペレータ端末４０と管理オペレータ端末４１）。

本来は、図１５に示される如く、同一構成の複数の端末装置ＰＣが、何れかのグループに属するオペレータが担当することで、指示オペレータ端末４０（指示オペレータＯＰ）と、管理オペレータ端末４１（管理オペレータＯＰ）に分類されるものである。

言い換えれば、ログインする第１グループ又は第２グループに属するオペレータによって同一構成の端末装置ＰＣが指示オペレータ端末４０と管理オペレータ端末４１との双方になり得る。

より詳しくは、指示オペレータ端末４０は、第１グループに属するオペレータが担当し、車両１２から通知される各支援要請のそれぞれに対応することを主たる機能（第１機能）とする。

一方、管理オペレータ端末４１は、第２グループに属するオペレータ（管理オペレータＯＰ）が担当し、オペレータ稼働状況データベース５４にアクセスして、複数の指示オペレータ端末４０（指示オペレータＯＰ）の稼働状況に関する情報を報知することを主たる機能（第２機能）とする。なお、管理オペレータ端末４１を操作するオペレータは、対峙する端末装置を、第２機能から第１機能へ機能を切り替えて動作させることが可能となっている。

図１５は、第９の実施の形態に係る自動運転制御装置と走行支援システムとの間で実行される支援要請に基づく情報の送受信制御を実行するための機能ブロック図である。

なお、第１実施の形態（図２参照）と同一構成部分については、同一の符号を付して、その構成の説明を省略する。

第９の実施の形態では、同一のハード構成とされた複数の端末装置ＰＣが設置されている。

図１５に示される如く、端末装置ＰＣは、指示オペレータ端末としての機能（第１機能）と、管理オペレータ端末としての機能（第２機能）とを備えている。

第１機能は、オペレータ情報記憶部６０、通信部６２、表示部６４、操作部６６、及び支援指示部６８で構成されている。

第２機能は、支援内容設定部７０及び優先度設定部７２で構成されている。

第１機能では、走行支援制御部１０Ａから支援対応指示を受け、かつ支援情報を取得することで車両１２（図１参照）への支援指示情報を出力する。第２機能では、走行支援制御部１０Ａから、支援内容確認指示及び優先度設定指示を受けて、支援内容設定情報及び優先度設定情報を返信する。

図１６において、端末装置ＰＣで実行される処理（図６と同等の走行支援システム側走行支援制御ルーチン）を、オペレータを主体とした流れで説明する。

なお、図１６において、第１の実施の形態で説明した図６と同一処理については、同一のステップ番号を付し、変更した処理については、同一のステップ番号の末尾に符号「Ａ」を付して説明する。

ステップ１５０では、車両１２の自動運転制御装置２０から支援要請があったか否かを判断し、肯定判定されるまで、待機する。

ステップ１５０で肯定判定されると、ステップ１５２へ移行して支援内容の確認を実行すること共に、優先度の自動設定を実行する。

優先度の自動設定は、実行可能な場合と不可能な場合がある。そこで、ステップ１５４では、優先度の自動設定の成否を確認し、ステップ１５６Ａへ移行する。

ステップ１５６Ａでは、第１グループのオペレータ（指示オペレータＯＰ）の空き状況を取得し、ステップ１５８Ａへ移行する。

ステップ１５８Ａでは、待機中の第１グループのオペレータがいるか否かを判断する。

ステップ１５８Ａで肯定判定、すなわち、待機中の第１グループのオペレータがいると判定された場合は、ステップ１６０Ａへ移行して、第１グループのオペレータへ対応を指示し、ステップ１６２へ移行する。

ステップ１６２では、ステップ１５４で確認した優先度の自動設定の成否を判断し、成功している場合は、このルーチンは終了する。

また、優先度の自動設定が失敗している場合は、ステップ１６４Ａへ移行して、優先度の設定を、以下の（ａ）又は（ｂ）の手段で実行し、このルーチンは終了する。

（ａ） 第２グループのオペレータが空き次第、手動設定
（ｂ） 第１グループのオペレータの支援状況に基づき、システムによる自動設定

ここで、ステップ１５８Ａにおいて否定判定、すなわち、待機中の第１グループのオペレータがいないと判定された場合は、ステップ１６６へ移行する。

ステップ１６６では、優先度は設定済か否かを判断し、否定判定された場合は、ステップ１６８Ａへ移行して待機中の第２グループのオペレータがいるか否かを判断する。このステップ１６８Ａで肯定判定されると、ステップ１７０へ移行して、支援内容の確認を指示すると共に、優先度の手動設定を指示し、ステップ１７２Ａへ移行する。

また、ステップ１６６で肯定判定（優先度設定済）された場合は、ステップ１７２Ａへ移行する。

ステップ１７２Ａでは、待機中の第２グループのオペレータがいるか否かを再度判断し、否定判定された場合は、ステップ１７４へ移行する。また、ステップ１６８Ａで否定判定された場合も、ステップ１７４へ移行する。

ステップ１７４では、支援要請対象を待ち行列へセットし、このルーチンは終了する。すなわち、ステップ１７４に到達した場合は、オペレータ端末への割り当ては無いことになる。

一方、ステップ１７２Ａで肯定判定された場合は、待機中の管理オペレータ端末４１があると判定され、ステップ１７６Ａへ移行する。

ステップ１７６では、繁忙時、すなわち、少なくとも待機中の指示オペレータ端末４０が存在しない状態での、オペレータ端末への割当処理を実行する。

なお、図６に関連するサブルーチン（図７～図１４）に関しては、以下のように、適宜読みかえればよい。
（読み替え１） 指示オペレータ端末→グループＡに属するオペレータ
（読み替え２） 管理オペレータ端末→グループＢに属するオペレータ

なお、第９の実施の形態は、上記表２において、第１の実施の形態に相当するものである。

１０ 走行支援システム、１０Ａ 走行支援制御部、１０Ｂ オペレーション制御部、１０Ｃ センタ側通信部、１２ 車両、１４ 車両制御装置、１６ カメラ群、１６Ａ 前方向カメラ、１６Ｂ 左前方向カメラ、１６Ｃ 左後方向カメラ、１６Ｄ 右前方向カメラ、１６Ｅ 右後方向カメラ、１６Ｆ 後方向カメラ、１８ レーダ群、２０ 自動運転制御装置、２２ ネットワーク、２２Ａ 無線通信装置、２４ インフラ管理システム、２４Ａ インフラ側情報管理部、２４Ｂ インフラ側通信部、３０ 検出情報格納部、３２ 走行制御部、３４ 支援要否判定部、３６ 車両側通信部、３９ 全体監視モニタ、４０ 指示オペレータ端末、４１ 管理オペレータ端末、４０Ａ 入力デバイス、４０Ｂ 出力デバイス、４１Ａ 入力デバイス、４１Ｂ 出力デバイス、５２ 支援制御部、５２Ａ 支援要請受信機能、５２Ｂ 支援内容判定機能、５２Ｃ 優先度設定機能、５２Ｄ オペレータ割当機能、５２Ｅ 支援発生予測機能，５４ オペレータ稼働状況データベース、５６ 支援発生予測用ビッグデータベース、５８ 支援ログデータベース、６０ オペレータ情報記憶部、６２ 通信部、６４ 表示部、６６ 操作部、６８ 支援指示部、７０ 支援内容設定部、７２ 優先度設定部、ＯＰ オペレータ（指示オペレータ及び管理オペレータ）

Claims (14)

1. 自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する走行支援システムであって、
   前記支援要請を受けたとき、第１グループに属するオペレータの入力操作情報に基づいて、前記自動運転車両の走行に関する指示情報を提供する第１機能、及び、第２グループに属するオペレータの入力操作情報に基づいて、前記第１機能による前記支援要請の対応状況を含む前記第１グループに属するオペレータの稼働状況に関する情報を報知する第２機能の何れかで動作可能な複数の端末装置と、（４０、４１）
   前記支援要請を受けた際、前記第１グループに属するオペレータに所定数の空きが有る閑散状態のとき前記支援要請の対応を前記第１グループに属するオペレータに割り当てる閑散時処理と、前記支援要請を受けた際、前記第１グループに属するオペレータに前記所定数の空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記第２グループに属するオペレータへの割り当てを検討する繁忙時処理と、の何れかを選択して実行する走行支援制御部と、（１０Ａ）
   を有する走行支援システム。（１０）
2. ログインするオペレータ毎に設定された所定の基準に基づいて、前記第１グループ又は前記第２グループに分類され、前記第１グループに属するオペレータが操作する前記端末装置が前記第１機能として動作する指示用端末装置であり、前記第２グループに属するオペレータが操作する前記端末装置が前記第２機能として動作する管理用端末装置である、請求項１記載の走行支援システム。
3. 前記第２グループに属するオペレータの入力操作情報に基づく前記第２機能として、支援要請の対象が複数存在する場合に、各支援要請に対する優先度の設定を含む、請求項１又は請求項２記載の走行支援システム。
4. 自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する指示情報を提供する走行支援システムであって、
   前記支援要請に対応して指示情報を各々が生成する複数の指示用端末装置と、
   前記指示用端末装置としての機能を備えると共に前記複数の指示用端末装置の動作状態を管理する管理用端末装置と、
   前記支援要請を受けた際、前記複数の指示用端末装置の中に空きが有る閑散状態の指示用端末装置が存在するとき前記自動運転車両から受ける複数の支援要請の各々の対応を閑散状態の指示用端末装置に割り当てる閑散時処理と、前記支援要請を受けた際、前記複数の指示用端末装置に空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記管理用端末装置への割り当てを検討する繁忙時処理と、が実行可能で、前記複数の指示用端末装置の動作状態に応じて、何れかの処理を選択して実行する走行支援制御部と、を有する走行支援システム。
5. 前記走行支援制御部における前記繁忙時処理が、
   前記優先度が予め定めたしきい値以上の高優先度の場合に、前記支援要請を、前記管理用端末装置へ割り当て、高優先度以外は前記指示用端末装置の空き待ち行列へ登録する、請求項４記載の走行支援システム。
6. 前記走行支援制御部における前記繁忙時処理の前に実行され、
   次回の支援要請の発生までの時間と、当該支援要請の優先度とを予測して、予測した時間内に予め定めたしきい値以上の優先度の支援要請が発生する確率が所定以上の場合に、今回の支援要請を、前記管理用端末装置へ割り当てる、請求項４又は請求項５記載の走行支援システム。
7. 前記走行支援制御部が、車両位置情報、走行ルート情報、交通量情報、天候情報、支援情報、及び支援対応時間情報を含むビッグデータを格納する支援発生予測用データベースを備える、請求項６記載の走行支援システム。
8. 前記走行支援制御部における前記繁忙時処理の前に実行され、
   指示用端末装置で対応している支援要請の中に、優先度が予め定めたしきい値以下の支援要請が存在する場合に、今回の支援要請を、しきい値以下の支援要請に対応している指示用端末装置の何れかに割り当てる、請求項１～請求項７の何れか１項記載の走行支援システム。
9. 前記走行支援制御部が、端末装置毎の現在の動作状態を格納する端末装置稼働状況データベースを備える、請求項８記載の走行支援システム。
10. 前記走行支援制御部における前記繁忙時処理の前に実行され、
    指示用端末装置で対応している支援要請に対して指示情報の提供が終了するまでの時間を予測し、予測時間が予め定めたしきい値以下の場合に、前記指示用端末装置の空き待ち行列へ登録する、請求項１～請求項９の何れか１項記載の走行支援システム。
11. 前記走行支援制御部が、支援要請を実行した履歴と、実行中の処理終了予測時間を格納する支援ログデータベースを備える、請求項１０記載の走行支援システム。
12. 自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する走行支援方法であって、
    前記支援要請を受けたとき、第１グループに属するオペレータの入力操作情報に基づいて、前記自動運転車両の走行に関する指示情報を提供する第１機能、及び、第２グループに属するオペレータの入力操作情報に基づいて、前記第１機能による前記支援要請の対応状況を含む前記第１グループに属するオペレータの稼働状況に関する情報を報知する第２機能の何れかで動作可能な複数の端末装置を備え、
    前記支援要請を受けた際、前記第１グループに属するオペレータに所定数の空きが有る閑散状態のとき前記支援要請の対応を前記第１グループに属するオペレータに割り当てる閑散時処理を実行し、
    前記支援要請を受けた際、前記第１グループに属するオペレータに前記所定数の空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記第２グループに属するオペレータへの割り当てを検討する繁忙時処理を実行する、
    走行支援方法。
13. 自動運転車両から通知される支援要請に対応して動作し、当該支援要請に基づき自動運転車両の走行を支援する指示情報を提供する走行支援方法であって、
    前記支援要請に対応して指示情報を各々が生成する複数の指示用端末装置と、
    前記指示用端末装置としての機能を備えると共に前記複数の指示用端末装置の動作状態を管理する管理用端末装置と、を備え、
    前記支援要請を受けた際、前記複数の指示用端末装置の中に空きが有る閑散状態の指示用端末装置が存在するとき前記自動運転車両から受ける複数の支援要請の各々の対応を閑
    散状態の指示用端末装置に割り当てる閑散時処理を実行し、
    前記支援要請を受けた際、前記複数の指示用端末装置に空きが無い繁忙状態のとき少なくとも当該支援要請の優先度に基づき前記管理用端末装置への割り当てを検討する繁忙時処理を実行する、
    走行支援方法。
14. コンピュータを、
    請求項１～請求項１１の何れか１項記載の走行支援システムの前記走行支援制御部として動作させる、
    走行支援制御プログラム。