JP7432683B2 - 遠隔操作可能な車両およびシステム - Google Patents

Description

本開示は、自律走行型車両及びそのような車両を複数含むシステムに関する。本開示は、自律走行の継続又は実行を妨げるような異常事態が検出された場合に、他の車両の運転者による車両の遠隔操作を可能にする。システムは、ある車両が支援を要求し、他の車両の運転者が、特に、車と車との間の遠隔操作、即ち、車間（V2V）遠隔操作の形で、又は現場支援によって、支援を提供できるように、システムに参加している全ての車両を通信可能に相互接続する。支援要求は、最適化された方法で発行および送信することができ、インシデントの種類に応じて、支援行動自体を決定することができる。システムは、車両が電車、地下鉄、バス及び／又はその類である公共交通システムであってもよいし、特に高速道路での長距離移動中の自律走行型トラック群、あるいは自家用車等であってもよい。本開示は、以下の説明で明らかになる多くの技術的利点を提供する。

私たちの社会の将来の交通に関するパラダイムは、タクシー、トラック、シャトルバス、自家用車などの道路上の車両や、路面電車、地下鉄、列車などの鉄道ベースの車両に自律走行装置を配備することを計画している。これらの車両が実装する自律性のレベルはさまざまだが、事故、すなわち異常事態が発生すると自律的なサービスが中断され、人間の介入が必要になる場合がある。このような混乱は、公共交通機関にとって特に重要である。例えば、路面電車や地下鉄が事故に直面した場合、1台の車両で事故が発生するとシステム全体が混乱し、何千人もの利用者に影響を与える可能性がある。遠隔操作センターにいるオペレータが車両を遠隔操作する古典的な遠隔操作（C2V）は、この問題にある程度対処できるが、特に物理的/現場での支援が必要な場合は、古典的な遠隔操作では解決できない。

上述のように、古典的な遠隔操作、すなわちC2V（center-to-vehicle）遠隔操作は、遠隔操作センターから車両を遠隔操作したり、遠隔操作センターから車両の運転手に支援／緊急指示を出したりするための公知手段である。例えば、特許文献１では、C2V遠隔操作と自律走行車を組み合わせ、車両が所定の状況を認識した場合に、車両の搭乗者に遠隔サポートを提供したり、遠隔操作センターから車両を遠隔操作したりすることが可能である。

米国特許出願公開第2015/0248131号明細書

特許文献１のシステムは、特に、自律走行が採用できない異常な状況においては、車両が遠隔支援を必要とすべき全ての可能な状況を予め決定することができず、支援が必要なだけ迅速かつ効率的に提供されない場合があり、遠隔操作者が現場支援を行うことができないため、柔軟性に欠けるという問題がある。さらに、遠隔操作センターのコストが高くなる可能性がある。

本明細書に記載された開示の目的は、上述した点を克服した車両及びそのような複数の車両を備えるシステムを提供することである。特に、他の技術的利点の中でも、車両が、柔軟に選択可能な制御モードの広い範囲を提供し、自律走行を妨げる事故が発生すべき時に自動的に支援／サポートを要求できるように改良され、そのような車両のシステムが、支援が柔軟に、迅速に、好ましくは事故のタイプに適応して提供されることを可能にする技術的解決策を提供する。

第１の態様によれば、自律走行モード、手動走行モード、および車間遠隔操作走行モードを提供する制御装置を備える車両が提供される。これらのモードは、柔軟に、好ましくは自動的に起動することができる。自律走行モードでは、車両（「エゴ車両」とも称され得る）の運転は自動的に制御される。すなわち運転は自動化され、自動化／自律走行機能は、制御装置の１つ以上のユニットまたはサブユニットによって、または車両に含まれるおよび／もしくはリモートサーバに含まれる別のユニットによって提供されてもよい。言い換えれば、自律走行モードは、人間の運転手の介入なしに、または可能な限りおよび／または法的に許可された範囲で、車両を制御する。手動運転モードでは、車両の運転は、運転手によって（主に）制御される。以下では、運転者と操作者の用語を互換的に使用することができる。車間遠隔操作走行モード（略称「V2V遠隔操作」）では、車両の走行は、他の車両に位置する人間の運転者によって遠隔操作され、ここで、他の／他の車両という用語は、それが車両／自車両ではないことを示すものとする。ただし、自車両の運転者は、状況に応じて、自車両のV2V遠隔操作装置を使用して、自車両を制御することができることに留意されたい。

さらに、車両は、「異常状況検出ユニット」とも称され得る支援要求ユニットを含み、車両が正常に動作する自律走行モードの使用を妨げる事故、すなわち異常状況が検出された場合、すなわち事故がない場合に、他の車両の運転者に支援要求を発するように構成されてもよい。言い換えれば、自律走行を継続または開始することができない異常な状況が検出された場合、支援要求が発行され、それによって支援が要求されることが可能である。この要求は、好ましくは、さらに以下に説明するように、運転者の携帯端末および／または他車両両のコックピットまたは他の出力ユニットに発行され得る。他の車両の運転者、他の車両、または支援要求を受信する任意のユニットは、「受信者」と命名されてもよく、支援要求送信の任意のターゲットは、「意図された／ターゲット受信者」と命名されてもよい。

さらに好ましくは、支援要求は、支援要求ユニットによってインシデントが検出された場合、及びエゴ車両に運転者が配置されていない場合にのみ発行される。第2の条件は、自車両の運転者が個人的に支援を行うことができるにもかかわらず、支援要求が発行されることを防止するのに役立ち、より迅速かつ効率的に支援を行うことができる場合がある。例えば、カメラが塞がれたことによるセンサ等の誤動作があった場合、自車両の運転手は、カメラを塞ぐものを取り除くなどの現場支援を行うだけでよく、自律走行が不可能な場合は自車両の運転手が手動運転を代行してもよく、自車両の運転手がV2V遠隔操作装置で自車両を制御してもよい。さらに、別の選択肢として、支援要求を他車両の運転者と自車両の運転者に発行し、自車両の運転者がその要求を受け入れることで、他車両の運転者が遠隔支援や現場支援を行わなくてもよいようにしてもよい。

さらに、V2V遠隔操作を可能にする車両の技術的構成により、支援要求は、要請の受信者が最適な解決策について柔軟に決定することを可能にし、他の車両の運転者が他の車両（この間、自律モードで運転）から遠隔で運転制御を引き継ぐか、運転者が、支援を必要とする車両の近くにいることがあるので迅速に可能でもある現場支援を決定することができるかもしれない。また、支援要求は、希望するサポートの種類に関する表示を含むように構成されてもよく、その表示は支援要求に自動的に追加されてもよく、及び／又は支援要求は、受信者が個人的に事故について判断することを可能にする情報を含んでもよい。すなわち、車両は、異なる走行モードを提供し、あらゆる種類の異常な状況において支援要求を生成し、発行するように構成されており、未知のまたは予期せぬ事故を考慮して柔軟性を低下させるような予め定められたものでさえない。このような技術的構成により、それに応じて、迅速かつ柔軟に支援を提供することができる。

さらに、車両は、その周囲を感知するためのセンサを含んでもよい。周囲とは、車両の周囲、または車両の前方、上方、後方、および／または側方の特定の領域であってよい。センサは、異なる種類のものであってもよく、「ライダー」装置、「レーダー」装置、カメラ、位置センサ、深層Lセンサまたは天候もしくは予報に関する情報取得ユニット、およびさらなる種類のセンサを含んでもよい。

図１は、車両、制御装置、および車両のコックピットの模式的な例を示す図である。 図２は、異なる種類の車両を含む2つのシステムの例を示す。 図３は、列車を含むシステム、インシデントを解決する方法を示す。 図４は、管理表の一例を示す図である。 図５は、支援要求先の選定方法を示す図である。 図６は、高リスクエリア検出時のマルチキャスト対応要求手順の例を示す図である。 図７は、高リスクエリア検出時のユニキャスト支援要求手順の例を示す図である。 図８は、経路遮断事故発生時のマルチキャスト支援要求手順の例を示す図である。 図９は、経路遮断事故に対するマルチキャスト対応要求手順の例を示す図である。 図１０は、経路遮断事故に対するマルチキャスト対応要求手順の例を示す図である。 図１１は、現地で待機している場合の手順の一例を示す図である。 図１２は、部品の異常が検出された場合の手順の一例を示す図である。

以下では、好ましい態様および実施例について、添付の図を参照しながらより詳細に説明する。異なる図面及び実施例における同一又は類似の特徴は、類似の参照数字で参照される。様々な好ましい態様及び好ましい実施例に関連する以下の詳細な説明は、本開示の範囲を限定するものでないことを理解されたい。

第１の態様によれば、自律走行モード、手動走行モード、および車間遠隔操作走行モードを提供する制御装置を備える車両が提供される。これらのモードは、柔軟に、好ましくは自動的に起動することができる。自律走行モードでは、車両（「エゴ車両」とも称され得る）の運転は自動的に制御される。すなわち運転は自動化され、自動化／自律走行機能は、制御装置の１つ以上のユニットまたはサブユニットによって、または車両に含まれるおよび／もしくはリモートサーバに含まれる別のユニットによって提供されてもよい。言い換えれば、自律走行モードは、人間の運転手の介入なしに、または可能な限りおよび／または法的に許可された範囲で、車両を制御する。手動運転モードでは、車両の運転は、運転手によって（主に）制御される。以下では、運転者と操作者の用語を互換的に使用することができる。車間遠隔操作走行モード（略称「V2V遠隔操作」）では、車両の走行は、他の車両に位置する人間の運転者によって遠隔操作され、ここで、他の／他の車両という用語は、それが車両／自車両ではないことを示すものとする。ただし、自車両の運転者は、状況に応じて、自車両のV2V遠隔操作装置を使用して、自車両を制御することができることに留意されたい。

さらに、車両は、「異常状況検出ユニット」とも称され得る支援要求ユニットを含み、車両が正常に動作する自律走行モードの使用を妨げる事故、すなわち異常状況が検出された場合、すなわち事故がない場合に、他の車両の運転者に支援要求を発するように構成されてもよい。言い換えれば、自律走行を継続または開始することができない異常な状況が検出された場合、支援要求が発行され、それによって支援が要求されることが可能である。この要求は、好ましくは、さらに以下に説明するように、運転者の携帯端末および／または他車両両のコックピットまたは他の出力ユニットに発行され得る。他の車両の運転者、他の車両、または支援要求を受信する任意のユニットは、「受信者」と命名されてもよく、支援要求送信の任意のターゲットは、「意図された／ターゲット受信者」と命名されてもよい。

さらに好ましくは、支援要求は、支援要求ユニットによってインシデントが検出された場合、及びエゴ車両に運転者が配置されていない場合にのみ発行される。第2の条件は、自車両の運転者が個人的に支援を行うことができるにもかかわらず、支援要求が発行されることを防止するのに役立ち、より迅速かつ効率的に支援を行うことができる場合がある。例えば、カメラが塞がれたことによるセンサ等の誤動作があった場合、自車両の運転手は、カメラを塞ぐものを取り除くなどの現場支援を行うだけでよく、自律走行が不可能な場合は自車両の運転手が手動運転を代行してもよく、自車両の運転手がV2V遠隔操作装置で自車両を制御してもよい。さらに、別の選択肢として、支援要求を他車両の運転者と自車両の運転者に発行し、自車両の運転者がその要求を受け入れることで、他車両の運転者が遠隔支援や現場支援を行わなくてもよいようにしてもよい。

さらに、V2V遠隔操作を可能にする車両の技術的構成により、支援要求は、要請の受信者が最適な解決策について柔軟に決定することを可能にし、他の車両の運転者が他の車両（この間、自律モードで運転）から遠隔で運転制御を引き継ぐか、運転者が、支援を必要とする車両の近くにいることがあるので迅速に可能でもある現場支援を決定することができるかもしれない。また、支援要求は、希望するサポートの種類に関する表示を含むように構成されてもよく、その表示は支援要求に自動的に追加されてもよく、及び／又は支援要求は、受信者が個人的に事故について判断することを可能にする情報を含んでもよい。すなわち、車両は、異なる走行モードを提供し、あらゆる種類の異常な状況において支援要求を生成し、発行するように構成されており、未知のまたは予期せぬ事故を考慮して柔軟性を低下させるような予め定められたものでさえない。このような技術的構成により、それに応じて、迅速かつ柔軟に支援を提供することができる。

さらに、車両は、その周囲を感知するためのセンサを含んでもよい。周囲とは、車両の周囲、または車両の前方、上方、後方、および／または側方の特定の領域であってよい。センサは、異なる種類のものであってもよく、「ライダー」装置、「レーダー」装置、カメラ、位置センサ、深層Lセンサまたは天候もしくは予報に関する情報取得ユニット、およびさらなる種類のセンサを含んでもよい。

支援要求、すなわちそれとともに送信されるデータは、支援要求を受信した他の車両の運転者が、例えば現場支援又は車間遠隔操作運転を含む適切な種類の支援を選択できるように構成されてもよい、事故に関する情報を含んでもよい。インシデントに関する情報は、例えば、インシデントが発生した車両からの写真、動画、ライブカメラ映像などを含んでもよく、及び／又は、センサの測定データ、気象データなどを含んでもよい。また、情報は、好ましくは、インシデントの種類に基づいて構成されてもよい。例えば、支援要求ユニットがカメラの故障を検出すべき場合、例えば、写真がすべて完全に黒、灰色または白などである場合、支援要求ユニットまたは車両の他のユニットは、カメラが故障していることを判別し、データ量を減らし送信時間を短縮するために、支援要求とともにカメラの写真のみを送信してもよい。

センサとサポートリクエストに関連情報を追加する可能性を提供し、好ましくはインシデントのタイプ/種類に応じて柔軟に構成することで、リクエストの受信者は最適な解決策、すなわちサポートのタイプを選択するために必要なすべての情報を手元に持つので、システムの柔軟性が向上する。予期せぬ事態でも適切かつ迅速に解決できるように、あらかじめ決められたインシデントのための厳格で固定された解決プロトコルを決定する必要はない。

また、別の好ましい構成に関連して以下でさらに説明するが、支援要求は、最適な支援タイプの指示を含むことができるが、支援要求の人間の受信者がその指示を「上書き」する、すなわち、彼／彼女が最も適していると思う支援タイプを選択することが可能であることが好ましい。

好ましくは、支援要求、すなわち送信データに含まれるさらなる可能な情報は、車両ID、車両の位置／場所、車両のセンサ／画像データを含む事件の種類、優先度スコア、及び／又はそのようなものを含んでもよい。優先順位スコアは、例えば、異なる車両からの複数の支援要求を単一の受信者が受信する場合、受信者がどの支援要求を優先すべきかについて決定できるように、事象のタイプ及びサポートの緊急性に基づいて決定されてもよい。

一般に、当該技術分野において知られているように、インシデントの決定／検出およびインシデントの種類の決定は、好ましくは、車両に含まれるユニットまたはサブユニット、非常に好ましくは支援要求ユニット、または関連データが車両から、例えば支援要求ユニットから送られる、リモートサーバで実行されてもよい。そして、そのようなユニットは、決定アルゴリズムに基づいてデータを処理するコンピューティングユニットであってもよく、および／または、異なる種類のインシデントを検出および／または区別するように訓練された人工知能／機械学習ユニットを含んでいてもよい。この訓練は、実際の運転状況からのデータ又はシミュレータからの運転データを用いて実行されてもよい。

さらに、自車両は、周囲を感知するセンサをさらに含んでもよく、制御装置は、既に上述したように、センサデータに基づいて検出されたインシデントの種類を決定するように構成されてもよい。適切なインシデント対応を選択するという観点での柔軟性および信頼性は、支援要求を構成するための、およびセンサデータなどの関連データを追加する際の上述したオプションによってさらに改善される。これにより、支援要求の受信者は、インシデントのタイプに関する自動判定に基づき、最適なソリューション／対策を選択するのに十分な情報を受け取ることができる。

さらに、インシデント種類の自動判定が提供される場合、支援要求部は、検出されたインシデントの種類に応じて、現場支援又は車間遠隔操作運転が必要／好まれるか否かの表示を含むデータを支援要求にさらに追加してもよい。インシデントの種類／種別は、好ましくは、センサデータ、環境データ、自車両の位置データ及び／又は同種のものに基づいて決定されてもよい。指示のためのいくつかの例が以下に提供されるが、例えば、他の指示が必要な他のインシデントが起こり得ること、または、指示が可能でなく、受信者が指示なしで決定する必要があることが示される場合があることに留意されたい。可能な指示方針の例は、以下を含むことができる。

また、進路遮断（走行）状況が判定された場合、他車両の運転者が、例えば、現場支援と車間遠隔操作運転のどちらが必要かを選択するように、支援要求には、何も表示しないようにしてもよい。あるいは、進路塞ぎ事態が検出された場合に、支援要求に現場支援指示を含めるか、V2V遠隔操作運転指示を含めるかを指示するようにしてもよい。

また、高リスク走行領域が決定された場合、支援要求には、車間遠隔操作走行が望ましいことを示す表示が含まれてもよい。

また、自車両の部品の故障が判定された場合、支援要求には、出張サポートが望ましい旨の表示が含まれてもよい。

また、悪天候と判断された場合には、車間遠隔操作走行が望ましい旨の表示を支援要求に含めてもよい。

なお、「現場支援」とは、特に、車両の（自律）走行の継続を可能とするために人が支援を行うこと、及び、その支援が車両の位置で行われることを意味するものとする。例えば、要支援車両のセンサがビニール袋で塞がれている場合、支援要求を受けた他の車両の運転者が、塞がれたセンサのある車両に行き、ビニール袋の除去や修理等を行うことができる。なお、「V2V遠隔操作運転」という用語は、支援を要請した車両を、他の車両のコックピットから他の車両の人間の運転手／オペレータが運転することを意味するものとする。これは、例えば、車両の走行経路が遮断され、自律走行制御が遮断要素を回避する方法を見つけることができない場合（ただし、人間の運転者には可能な場合がある）、又は、例えば、天候があまりにも悪い場合、又は歩行者などによって非常に混雑したエリア（高リスクエリア）なので人間の運転者が自律走行制御よりも安全に当該エリアをナビゲートできる場合に必要となる場合がある。

好ましい動作手順／方法は、以下のステップを含んでもよい。

支援要求部は、自車両が高リスクエリアにいること、又は、部品に異常があることを検出すると、V2V遠隔操作の必要性を示す支援要求をオペレータ（運転者）が搭乗している他の車両に出力する。他車両両の運転者がいる場合、運転者は、V2V遠隔操作の要求を受け付け、受け付けた運転者がいる他車両両の遠隔操作装置から出力される遠隔操作情報に基づいて、V2V遠隔操作を実行する。なお、遠隔操作情報は、他車両両において、例えば、遠隔操作用コックピットの画面等に表示／出力される自車両の画像やセンサデータ等のライブストリームを含んでもよい。

さらに、エゴ車両は、部品の故障が検出された場合、エゴ車両の外部にいるオペレータに対して、現場支援（「現認」支援ともいう）のための支援要求を送信することができる。

さらに、自車両が前方にいる／進路を塞がれていることが検知された場合、自車両は、複数の種類のセンサが感知したセンサ情報を他車両両の運転者に出力し、受信者が最適な支援を決定できるようにする。

以上のことから明らかなように、支援要求を受けた者が、必要とする支援の種類の決定を完全にサポートし、最も効率的かつ効果的に問題／事件を解決するための支援を選択することができるので、あらゆる種類の事件に柔軟かつ迅速に対処し解決することができる。あらかじめ決められた厳格なアシスタンス手順が必要なく、他のドライバも利用できるため、テレオペレーションセンターからしか車両を操作できない状況とは異なり、迅速な現場でのアシスタンスが可能でさえある。高価な遠隔操作センターは必要ないが、アシスタンスの選択肢を増やすために追加することは可能である。つまり、上記の現場アシストとV2V遠隔操作に加えて、センターからの遠隔操作（C2V遠隔操作）を選択することも可能になる。

さらに、支援要求部は、ユニキャストまたはマルチキャストのいずれで支援要求を生成し、発行／送信／送信してもよい。送信モードの選択については、ユニキャストを使用する場合とマルチキャストを使用する場合の「送信ポリシー」がテーブル等に基づいて予め決められているなど、好ましい態様が異なるが、ここでは、ユニキャストを使用する場合とマルチキャストを使用する場合の「送信ポリシー」について説明する。さらに、代替的に、検出されたインシデントの種類によって送信モードを決定するような構成も可能であり、これもテーブルで定義することができる。また、上記いずれの選択肢においても、「不明／未定義」のインシデントが発生した場合、送信モードをマルチキャストまたはユニキャストのいずれかにすることをテーブルまたはデータベース等に定義しておくことにより、柔軟性が保たれ、不明インシデントにも対応できるようにすることも可能である。さらに、非常に好ましくは、上記のオプションを組み合わせて、予め定義された送信ポリシーとインシデントのタイプの両方を使用して送信モードを決定するようにすることができる。

上記ポリシーを格納するためのテーブル、データベース、または他のタイプのオプションは、車両のコンピューティングユニットのメモリに格納されてもよいし、情報が読み取られなければならない／必要とされるときに車両が通信可能に接続するリモートサーバのメモリに格納されてもよい。

異なる事件または一般的な「条件」が、ユニキャストの支援要求を他の状況よりも効果的かつ効率的にし、またその逆もあり得るため、異なる送信モードを使用するオプションは、ここで提案する開示の柔軟性をさらに支持する。例えば、車両のあるシステム又はある地域の統計が、過去に現場支援がかなり頻繁に、問題解決のためのV2V遠隔操作と同程度に必要とされたことを示唆する場合、「送信方針」表は、ユニキャスト送信モードを一般的に使用することと、他の車両の最も近い運転者／操作者を主要な（最も優先度の高い）対象受信者とすべきことを示すかもしれない。さらに、アシスト／支援要求の数が多いと予想され、かつ、現場アシストとV2V遠隔操作の数が同程度になる場合には、最も関連性の高い、例えば最も近い他車両の運転者をターゲットとする複数のユニキャストモードが送信ポリシーテーブルに示されてもよい。さらに、ほとんどの要求がV2V遠隔操作で解決でき、システム規模が大きく（例えば、100台以上）、かつ/または支援要求の数が多い（例えば、1日＆車両あたり100件以上）ことが予想される場合、人間のアシスタントの数を減らすためにマルチキャストが最も適していると表示してもよく、さらに、支援要求ピーク時にC2V遠隔操作の選択肢を追加するために遠隔操作センターを追加してシステムをサポートしてもよい。また、悪天候などで支援要求の頻度が高くなる場合、特に公共交通機関では、一時的に「支援者」であるドライバを増員することも可能である。

さらに、自車両（及び他の全ての車両）は、システム内の車両について、システム内に存在する各車両又は割り当てられた車両群のID等の車両識別情報、手動又は自律等の車両の運転モードを示す運転モード情報、搭乗中の運転者／ドライバ情報運転者が乗車しているか否かを示す運転者乗車情報、運転者が空き／支援可能であるか否かを示す運転者／運転者状態情報であり、支援要求部は、好ましくはユニキャスト送信モードの場合に、管理テーブルの情報および／または各他車両の位置情報に基づいて支援要求を送信するようにさらに構成されてもよい。管理テーブルは、各車両から一元的にアクセスできるように、遠隔地のサーバシステムに設けてもよいが、各車両に設けることが好ましい。また、車両とリモートサーバとの間で通信障害が発生した場合でも、各車両間で直接通信を行うことにより、本システムを動作させることが可能である。

管理テーブル、データベースなどは、支援要求送信の効率的な調整を可能にする、信頼性が高く複雑でない選択肢を提供する。これは、ユニキャスト送信モードの場合にさらに当てはまり、例えば、支援要求の送信は、好ましくは管理テーブルからの情報を考慮し、例えば、利用できないドライバをターゲット受信者として選択しない、及び／又は他の車両の位置は、支援要求を送信するための主要／優先ターゲット受信者として次に使用される最も近い車両を決定するために使用することができるためである。また、車両に運転手がいないことが表に記載されている場合、その車両を対象者として無視するようにしてもよい。

例えば、目標受信者を決定するための好ましい方法において、エゴ車両（またはこのタスクのための専用のユニット／サブユニット）は、
（ステップ１）管理テーブルがリモートサーバに集中的に格納されている場合、管理テーブルを格納する制御サーバから各車両の位置／ロケーションデータを受信してもよい。その他、管理テーブルが集中的に格納されておらず、各車両に格納されている場合、自車両は、その格納スペースに格納されている管理テーブルの情報を単に検索する。

(ステップ２）管理テーブルを使用して、オペレータ／ドライバの利用可能性を確認し、関連性によってランク付けし、好ましくは、エゴ車両までの距離によってランク付けすることを含む。

(ステップ３）最も関連性の高い、例えば最も近い、利用可能な運転者／オペレータが決定され、それに支援要求が送られる。この支援要求は、当該運転者／オペレータの車両及び／又はその携帯端末に支援要求を送ることを含んでもよい。

このような方法により、少ない操作ステップで、最適な（第一の）対象者を選択することができる。これにより、複雑さが少なく、計算の労力も無視できるほどで、迅速かつ効率的なサポートが可能となる。

さらに、自車両、および他の全ての車両またはリモートサーバは、支援要求の可能性のある受信者に関する優先度情報を含む優先度テーブルを構成してもよい。そして、ユニキャストで支援要求を送信する場合には、まず、優先度テーブルにおいて最も高い優先度を有する支援先に対して支援要求を送信する。これにより、上記管理テーブルを用いる場合よりも、さらに少ない演算量で対象受信者の選定を高速化できる可能性がある。ただし、非常に好ましくは、優先度テーブルと管理テーブルとを組み合わせて、例えば、最初のステップで、優先度テーブルを用いて、最も優先度の高い運転者／操作者を選択し、さらなるステップで、管理テーブルの情報に基づいて、当該運転者が利用可能かどうか等を調べるクロスチェックを行うようにしても良い。

なお、優先順位テーブルの使い方としては、例えば、支援要求をユニキャストで送信すると決定した場合（あるいは、予めユニキャストをデフォルトの送信モードとして設定している場合など）、優先順位テーブルを利用して、他の車両にいるドライバ／オペレータの中で優先順位が高い人から順に支援要求を送信することなどが考えられる。さらに、オプションとして、前記オペレータが不在であるか、または予め設定された待機時間内に前記支援要求に応答しない場合、前記要求は、マルチキャストとして残りのオペレータ／ドライバに送信されてもよいし、ユニキャストで次に高い優先順位の対象受信者に送信されてもよい。

以下により詳細に説明するように、優先順位テーブルは、定期的に更新されてもよく、例えば、好ましくは、少なくとも（グループ化された）車両の１つのオペレータ状態または動作モードが変更されたときに、優先順位テーブルが更新されたときに、他の車両内のすべての優先順位テーブルに更新情報が共有される（テーブルがリモートサーバに集中的に格納されない場合は、前記最後のステップが不要になる）。「グループ化された」車両という用語は、好ましくは、これらの車両によって形成されるシステム内で通信可能に接続されているすべての車両に関連するものとする。

具体的には、さらに、好ましくは、予め設定された変更／更新イベントが発生した／検出された場合に、管理テーブル及び／又は優先順位テーブルが更新されてもよい。例えば、管理テーブルの更新イベントとしては、車両の運転モードの変更、運転者の携帯端末と当該運転者の車両との接続の喪失（携帯端末が支援要求の受信に用いられる場合）、運転者の携帯端末と車両との新たな通信接続の検出、運転者のステータスの変更、等が考えられる。また、上述したように、テーブルを一元的に記憶する場合には、車両からのテーブル変更要求をトリガーとして一元的に更新を行うことができるが、各車両がテーブルのコピーを記憶する場合には、システム内にある他の全ての車両、すなわち、システム内にグループ化されている車両に対して更新後の情報／テーブルを送信することも可能である。

優先順位テーブルのイベントには、（グループ化された）車両の１つのオペレータの状態または運転モードが変更されたこと、車両が（少なくとも一時的に）引退したこと、が含まれ得る。更新は、管理テーブルに関連して上述したのと同じ選択肢に従って実行することができる。

この更新により、支援要求を効率的に送信することが可能となり、支援要求の紛失や未達を最小限に、あるいはゼロにすることができるため、通信量を削減することができる。

さらに、エゴ車両は、無線でデータを送受信するように構成された通信装置、および／または、エゴ車両または他のビークルに運転コマンドを出力するように構成された運転装置と、エゴ車両または他のビークルの周囲の状況および車両制御データを選択的に表示するように構成されたディスプレイを含む操縦室を含むことができる。運転装置は、車両を制御することができる任意の種類のツール（複数可）／手段であってよく、すなわち、ハンドルであってもよく、「ジョイスティック」であってもよく、アクセルスティック（地下鉄などの場合、地下鉄の列車の運転を制御するにはこれで十分である）であってもよく、あるいは他のオプションであってもよい。すなわち、好ましくは、運転装置は、車両を制御するハードウェア手段であるが、タッチパネル／ディスプレイに設けられた仮想ボタン等であってもよい。さらに、ディスプレイは、センサデータ、カメラデータ等、すなわち、車両を制御するために有用または必要となり得る全ての情報を出力してもよい。また、2つの装置は、V2V遠隔操作を可能にするように構成されており、これは、特に好ましくは、V2V遠隔操作を適用する場合、制御データ及び表示されるデータが、自車両を操作する場合とは異なる経路で行われることを意味する。さらに他の言葉で言えば、自車両またはエゴ車両を制御する場合、走行装置は、当該技術分野で知られているコントロールバイワイヤの場合のように、自車両／エゴ車両の関連デバイス／ユニットに走行指令データ／信号を出力して、車両を制御できるようにしてもよい。さらに、自車両のセンサ、カメラ等のデータを画面に表示する。そして、V2V遠隔操作の場合、前記制御データは、制御信号として自車／他車両のユニット／装置に送信されるのではなく、自車（送信側）の通信装置と他車両（受信側）の通信装置（受信側）を介して、それぞれのユニット／装置に送信される。その逆に他車両両は、そのセンサデータ等を自車両のディスプレイに送信する。非限定的な具体例として、例えば、他車両両の運転手がV2V遠隔操作で制御されている「自車両」である列車を加速させたい場合、他車両両の運転手はアクセルノブ／スティックを使用してモータに加速指令信号を出すが、当該信号はV2V遠隔操作されている自車両のモータに伝達される。

任意に、車両は、他の車両の遠隔操作のためにのみ設けられた遠隔操作装置又はコックピットを含むこともできる。これにより、自車両を制御するための操作部品／駆動装置と、V2V遠隔操作を行うための操作部品／駆動装置とを物理的に分離することが可能となる。このように明確に分離することで、誤った装置を選択するなどの混乱を避けることができるが、自車両の制御とV2V遠隔操作のために相互／共通のコックピットを設けることで、コックピットの必要物理スペースを縮小することが可能となる。

また、車両の制御装置とは別に、V2V遠隔操作に関連する全てのタスク（信号の経路変更など）を管理／実行する専用の遠隔操作ユニットを設けてもよい。

さらに、車両は、さらに他の共通ユニット、例えば、さらなるディスプレイ、自動車、列車などで通常用いられる電子制御ユニット、さらなる制御およびセンサ、制御装置に含まれていない場合は専用の自律走行ユニット／モジュールなどを含み、車両またはそれぞれのタイプから知られているようにすることができる。言い換えれば、本明細書で説明する車両または当該車両の制御装置は、それぞれの車両の既知の構成／装備に加えて、上記のユニットなどを含んでもよい。本開示の機能は、例えば、ソフトウェア更新によって、及び／又は、追加のハードウェアモジュールの形態で上述のユニットを導入することによって、既存の車両に追加されることさえある。

さらに、自車両は、データ交換のために運転者の携帯端末と無線又は有線で接続するように構成されたインターフェースを含み、運転者の携帯端末がインターフェースに接続されたとき、例えば運転者が車両にログインしたとき、携帯端末の画面に他の車両の支援要求が表示されるようにしても良い。あるいは、サポートリクエストを車両のディスプレイに表示してもよいし、その両方を表示してもよい。

上記のような車両のハードウェア構成により、本明細書で説明する支援要求機能およびV2V遠隔操作機能を、大きく複雑化することなく、かつ、全ての走行モードにおいて信頼性の高い動作を可能とすることができる。

さらに、自車両の制御装置は、管理テーブルが自車両の運転者ステータスが空き／利用可能でないことを示す場合、他の車両の支援要求に対する返答として拒否コマンドを自動的に送信してもよい。これは、特にマルチキャスト送信のシナリオにおいて、計算コストと時間を削減する管理テーブルなどを参照する必要なく、多数の他の車両に支援要求を発行したエゴ車両が、すべての他の車両／運転者の利用可能状態について瞬時に知ることができるので、好ましい選択肢であると考えられる。

さらなる態様は、上述した少なくとも１つの選択肢による複数の車両を含むシステムに関し、いくつかの車両では運転者が存在し、他のいくつかの車両では運転者が存在しない。車両は、ネットワークを介して互いに通信可能に接続されてもよく、これは、「グループ化された車両」とも呼ばれ得る。ネットワークインフラは、WANであってもよいし、私的に運用される他のタイプのネットワークであってもよく、ここで、私的とは、例えば、公共交通機関の所有者等によって運用される通信網を意味するものとする。このような構成により、オーダーメイドのセキュリティオプションと、確保された帯域幅とともに非常に高い通信速度と低遅延を実現することができる。他方、通信ネットワークは、「公衆」であってもよく、これは、好ましくは、例えばスマートフォン等との移動通信に使用される、各通信ネットワーク事業者の移動通信ネットワークを意味／示すものとする。これは、本開示のシステムが、コストを節約し、独自のネットワークを構築する必要がない既存のインフラに依存することができるという利点を有するが、テーラーメイドのソリューションの可能性を低下させ、帯域幅、可用性などが不足する可能性がある。

さらに、システムは、好ましくはV2V遠隔操作の追加オプションとして、１つ以上の車両の遠隔操作センター遠隔操作（ここで、遠隔操作センターから同時に遠隔操作できる車両の数は、当該センターにおけるオペレータの数によって制限される）を提供するための遠隔操作センターを含んでもよい。この場合、システム内の車両の制御装置は、別の運転モードであるC2V遠隔操作運転モードを含んでもよく、しかしながら、V2V遠隔操作運転モードと同様に構成されてもよく、そのとき、管理テーブルは、遠隔操作センターにおけるオペレータの状態を示す別のエントリを含んでもよい。さらに、支援要求は、C2V遠隔操作の要求または優先を示す追加のオプションを提供してもよく、これは、管理テーブル等において利用可能であると示された他車両の運転者がいない場合であってもよい。すなわち、C2V遠隔操作により、支援の信頼性及び継続性を確保するための別の選択肢を追加してもよい。

＜本開示の一般的説明及び好ましい態様＞
交通の未来は、おそらく自動車の自律運転と遠隔操作という2つの異なるパラダイムが融合されることになる。（半）自律走行車は99.99％の時間、自律的に走行するが、前進して問題を解決するために人間の支援が必要になることがある。このような事故や異常事態は非常に多様であり、起こりうるすべての種類の事故をあらかじめ分類し、それに対して所定のアクションを適用することは不可能である。

本開示は、これらのインシデント、特に、予め定められたインシデントのリスト内で予見されていないインシデントを、遠隔操作及び／又は現場（「現認」とも呼ばれる）支援によって問題を解決できる人間の支援者（「オペレータ-テレオペラ」とも呼ばれる）に制御要求を送ることによって柔軟に処理する効率的な方法を提案するものである。支援者は、本開示内では、通常、他の車両の運転者である。例えば、制御要求は、遠隔操作／現場支援が必要となる車両から他の車両に、送られることとなる。したがって、本明細書で提案する解決策は、より効率的、柔軟かつ信頼性の高いサービスを提供する目的で、自律車両及び半自律車両の現場支援及び遠隔支援を活用する。上述したように、人間による支援の好ましい可能性は、以下の通りである。遠隔操作（例：混雑した場所での車両の制御）、および現場での支援（例：車両のセンサを遮るビニール袋の除去、車両の走行経路にある遮蔽物の除去）。

特に、記載されたシステムは、複数の参加／グループ化された車両を含み、これは、好ましくは、システムの車両が、システム内で互いに通信可能に接続されることを意味するものとする。これは、通信ネットワーク、好ましくは無線ネットワークによって実現されてもよい。したがって、ここでは、特に、参加車両のコックピットが、古典的な人間の操作と遠隔操作のための交換可能なモードを有する遠隔操作のために構成されるシステムが開示される。遠隔操作モードは、（主に）V2V遠隔操作モードであり、これは、例えば、車両「A」が別の車両「B」から遠隔操作されることを意味する。システム内の車両は、動作モードと、V2V遠隔操作の実現に必要なそれぞれのソフトウェア及びハードウェアとに関して、全て同一又は類似の構成を有する。車両は、可能な限り自律的に走行するように構成された車両であることが好ましく、つまり、自律走行を妨げる事故が発生していない／検出されていない場合に、自律的に走行するように構成された車両であることが好ましい。

遠隔地にある遠隔操作センターから車両が操作／制御される（すなわち、C2V遠隔操作）、V2V遠隔操作の可能性を含まない遠隔操作センターに比べて、人間のオペレータ／遠隔操作者がサービス車両の近くにいるため、ここに提案するソリューションによって車両の自律および半自律操作をより効率的に利用できることは、さらなる技術的優位点である。遠隔操作とは、通常知られているように、車両の運転者ではなく、遠隔地にいる者から車両を制御／運転することを意味する。V2V遠隔操作とは、他の車両に搭乗している者が、V2V遠隔操作される車両を操作することであり、以下、自車両を「自車両」、遠隔操作者／運転者が搭乗している車両を「他車両」と称することがある。C2V遠隔操作とは、運転者（この場合むしろ運転者である）が、遠隔の静止センターに存在し、そのセンターから車両を操作するために装備されていることを意味するものとする。

本明細書で提案するシステムの車両のハードウェア構成に関して、好ましくは、V2V遠隔操作制御装置に関して、同一または少なくとも同様のコックピット装置（制御装置）を、本明細書で提案するシステムの各車両に提供する。制御装置は、自律走行モード、手動走行モード、および車間遠隔操作走行モードを提供する。別の同様の車両からの自律または半自律車両の遠隔操作を向上させることができる。これは、車両のV2V遠隔操作を引き継ぐ運転者が、遠隔操作を安全に、かつ時間のかかる訓練を必要とせずに行うことを支援する。本システムの各車両は、好ましくは、マスタ車両またはスレーブ車両のいずれかとして遠隔操作に使用することができるようにしてもよい。V2V遠隔操作中のデータフローに関しては、異なるセンサおよび処理アルゴリズムからの情報がV2V遠隔操作車両から遠隔操作車両のリモートディスプレイに送られ、同様に遠隔操作者のコックピットからの制御動作が遠隔操作車両のアクチュエータにリンクされることが好ましい。要約すると、すべての車両は少なくとも以下のことが可能である。運転手による手動操作（古典的操作）、（半）自律的操作、他の車両からのV2V遠隔操作、他の車両のV2V遠隔操作に使用される。

本開示の具体的な実施例は、非限定的な例として、複数の鉄道車両を含む鉄道システムに関するものであってよい。例えば、鉄道システムは、車両移動の頻度が高い鉄道輸送線であってもよく、線路は、都市部の地下鉄線などの場合であってもよいように、さらなる特定なしに循環型または双方向型であってもよい。この非限定的な例を用いて、可能な事故処理方法をさらに以下に説明する。

＜本開示に係るシステムの車両（複数可）の構成＞
図１ａは、本開示の車両100を概略的に示し、図１ｂは、後で説明する異なる制御装置及びユニットを含む当該車両100の制御装置1の可能な構成を概略的に示し、図１ｃは、車両100の（遠隔操作）コックピット102を概略的に示している。

図１ａ、１ｂによって示されるような制御装置1は、自律走行モード、手動走行モード、及び車間遠隔操作走行モードを提供する。自律走行モードでは、車両100の走行が自動的に制御可能であり、手動走行モードでは、車両100の走行が運転者によって制御可能であり、車間遠隔操作走行モードでは、車両100の走行が他の車両に位置する運転者によって制御可能である。制御装置1は、単一のコントローラハードウェアに統合されてもよいし、別個の存在であってもよいデバイス、モジュールまたはユニットを介して異なる技術的機能を提供することが可能である。また、図１ｂに示されるようなデバイス等の分布は必須ではなく、デバイス／ユニット等は示されたデバイス／ユニットのいくつかが他のエンティティに合併されるか、またはさらに分散されるなど、異なるように配置されてもよい。すなわち、示されたようなアーキテクチャは概略的なものであり、ユニット及びデバイスは、その意図された技術的機能を逸脱することなく、異なるように配置されてもよい。また、図示する装置／ユニット／モジュール等は、ハードウェア及び／又はソフトウェアによって構成されてもよく、好ましくは、1又は複数のプロセッサと、コンピュータプログラムを保存するための内部及び外部の記憶空間と、データベースを保存するための記憶空間と、等によって構成される。さらに、制御装置1は、単一のユニットであってもよいし、また、車両100上に局所的に分散された複数のユニットに分割されていてもよい。図１ａでは、可能な一例として、制御装置を単一のユニットとして示している。

制御装置1および車両100の接続コンポーネントの構成に関して、可能な構成例が図1bによって示されており、異なる技術的機能性は、例えば、異なるハードウェアデバイス／ユニット／モジュール内に編成することができる。

１） AD ECU 12 (Autonomous Driving Electronic Control Unit：自律走行型電子制御ユニット)は、車両の自律運転に必要な知覚、定位、軌道計画に必要な計算の大部分を実行するコンピュータまたはコンピュータの集合を指す。AD ECU12は、車両の自律制御の既知の原理に従って動作することができる。

２）制御装置1は、図１ａに示すように、１つ以上のセンサ101に通信可能に接続されてもよい。センサ101のリストは、特に、自律動作要件によって定義され、したがって、車両のタイプおよび展開シナリオに従って変化し、それは、カメラ、ステレオカメラ、イベントベースカメラなどのパッシブ光学センサ101、LiDAR、RADAR、SONAR、GNSS／INSおよびIMUなどのようなアクティブ光学センサ101などを含むことができる。

３）システムの通信インフラ（図示せず）は、アプリケーションが許可する場合、プライベート無線エリアネットワーク（WAN）を含んでもよい。例えば、都市における公共交通システム、鉱山で動作する車両100、150～158などの場合、または通信プロバイダを通じて、好ましくは5Gなどの高速帯域を有する公共ネットワークの使用である。制御装置1は、車両100がシステムの他の車両、および利用可能な場合には遠隔操作センターまたはリモートサーバ（図示せず）とデータを交換できるように、車両100を上記通信インフラに通信可能に接続することができる通信装置103を含むかまたは接続することができる。

４） 制御装置1または遠隔操作ECU10は、他の車両との通信を担当するコンピュータおよびルータを指し、その役割は、遠隔操作のための情報送信とともに、異なる車両の状態および人間の補助者の位置に関する情報を共有することであってもよい。また、遠隔操作ECU10の機能は、専用の遠隔操作ECUが不要となるように、他のユニットに統合されてもよい。さらに前記遠隔操作ECUは、制御装置10とも呼ばれ、車両100、150～158の異なる制御モードを選択し提供するための技術的機能を統合してもよく、好ましくは、支援要求ユニット11が、前記制御装置10のサブユニットであってもよい。

5)制御装置1または駆動装置104は、図１ｃに示すように、人間が運転する車両に存在する、車両を手動で制御するための全ての装置を意味する。ここで、図１ｃには、操縦桿104aとボタン104bが示されている。

6）遠隔操作用及び／又はエゴ車両の運転者のためのコックピット102も提供され、これは、センサデータが表示されるディスプレイ（複数可）105を含み、人間が現在の車両100（自律的に動作するか停止中であってもよい）のコックピットから遠隔車両150～158を遠隔操作し、両方のモード間で最小限の変更で現在の車両100を標準運転（人間運転）で駆動することができるよう、求められるものである。可能な実装は、人間のオペレータへの感覚の干渉を避けるために、従来のフロントガラス窓を使用せず、遠隔操作と標準／手動操作のために同じディスプレイ105を使用することができる。同様に、コックピット102は、移動中の自律車両から遠隔車両150～158を遠隔操作している間の感覚の混乱を避けるために、車両振動からできるだけ隔離されていてもよい。コックピット102の可能な概略図は、例示的に、制御ボタン104b、運転スティック104a、およびディスプレイ105を示す図１ｃによって示されている。

さらに、図１ｂに示すように、車両100の制御装置1は、車両100のローカルにデータを格納するための記憶装置17と、通信およびセンサデータ制御、エンジン制御、ブレーキ制御、学習済み人工知能（AI）または機械学習ユニット（ML）など、異なる技術タスクを有することができる他の制御ユニット13～16を含んでもよい。さらに、ユニット13～16のうちの１つは、運転者のモバイルコンピューティングデバイスとコックピット102または車両100との間の通信接続を確立するためのインターフェースであってもよい。

要約すると、車両100は、電車や自動車などのそれぞれのタイプの既知の自律走行車両に基づく制御設定を含んでもよく、さらに、制御装置1または制御装置10は、V2V遠隔操作のための、事故の検出を行うための、および支援要求を生成し、発行するための追加の制御モードと、好ましい例では手動運転モードのための通常のコックピットと共有されてもよいV2V遠隔操作用の制御装置または駆動装置104、通信装置（複数可）103およびコックピット102などの他の車両150～158のV2V遠隔操作を可能にするハードウェアを含んでいてよい。支援要求ユニット11は、サブユニットとして制御装置1に統合されてもよいし、遠隔操作ECU10などの他のユニットのうちの１つの一部であってもよい。支援要求ユニット11は、好ましくは、インシデントを検出し、インシデントの種類を決定し（可能であれば自動的に）、支援要求を生成し、発行するとともに、着信した支援要求を処理するように構成されてもよい。支援要求ユニット11または制御装置1の他の部分は、インシデントを検出するため、および／またはインシデントの種類を決定するために訓練されたAIまたはMLユニットを含んでもよい。このような目的のために使用される訓練データは、AI／MLを訓練することができるように、テストドライバがテストドライブ中にインシデントを強調する、実車でのテストドライブまたはシミュレータでのテストドライブから得ることができる。その他、一般的なコンピュータプログラムのアルゴリズム及び手順も、すなわちAI又はMLを使用せずに、既知の原理に従って、インシデントの検出及びそのタイプの決定のために使用することができる。例えば、車両100のそれぞれのセンサ101が、将来の走行経路に物体が置かれたことを検出した場合に、走行経路の遮断を検出することができ、あるいは、センサの測定値が正常範囲から外れた場合に、誤動作があると結論づけることができる、等々である。それぞれのプログラムは、図１ｂに示すような車両100の記憶装置17に格納することもできるし、遠隔地にあるコンピュータ（「クラウドコンピュータ」）などに格納することもできる。

図２は、本主題に該当する2つの異なるシステムの例を示しており、一方のシステムは公共交通機関の列車を含み、他方のシステムはトラックを含むシステムを示している。しかしながら、一般的な原理は、車両100の種類に関係なく同じであり、図２の両方の例のシステムについて、運転手を含まない車両151、152が存在し、運転手が存在する車両100が存在することが、模式的に示されている。もちろん、システムは、3台未満の車両を含むことができ、好ましくは、図２の実施例に示される3台よりもはるかに多くの車両を含むことができる。さらに、無人車両100、150～158と運転手が存在する車両100、150～158との好ましい比率は、柔軟であり、日々決定することができる。例えば、特定の日に、予想される悪天候などにより多くの支援要求が出される可能性があると予想される場合、公共交通事業者は、支援要求の量が少ない／通常であると予想される他の日に比べて、当該日に多くの運転手を予定することができる。

図３は、車両100のユニット／デバイスの１つ、好ましくは支援要求ユニット11または制御装置10内で実行されるコンピュータプログラム製品によって実行され得る方法の可能な実施例を示している。アプリケーションシナリオは、図３ａに示すように、10台の車両100、150～158および5人の運転手-遠隔操作者（またはドライバまたはオペレータ）を有する円形の公共輸送ラインに関する。ここで、車両150、152、154、155、157は運転手を含み、車両100は「エゴ」車両として事件に直面することになり、車両151、153、156、158は運転手を有しない。なお、車両の数、運転者の数、システムの種類は一例であり、異なる場合がある。車両100、150～158は、デフォルトモード（インシデントなし）である自律走行する。自律走行を妨げるインシデントを検出すると、インシデントに直面した車両100は、支援要求を生成し、送信する。オペレータ-遠隔操作者は、現在の車両100から、または遠隔の車両150～158から、支援要求（簡単に言えば、リクエスト）を受信することができる。利用可能なオペレータ-遠隔操作者は、要求を受け入れてもよく、事件が遠隔操作によって解決できない場合、オペレータ-遠隔操作者は、それぞれの車両に最も関連するオペレータ-遠隔操作者に送信される現場支援の要求を提起してもよい（例えば、最も近いもの）。a) 車両の数とアシスタント（支援者）の数、b) 要求の頻度と性質、c) アシスタントの遠隔車両への近接度によって、支援要求の送信と受信に関するより複雑なポリシーが特定の実装に対して提案され得る。

＜支援要求の生成と配布のための運用方法＞
図３ｂは、好ましい態様を示す。S1では、デフォルトの運転モードとして、全ての車両100、150～158が自律的に運転する。自車両100の安全な自律運転を妨げるインシデントが発生すると、自車両100により支援要求が生成され、他の車両150～158（運転者である人間支援者）に送信される（S２）。支援要求は、好ましくは、車両識別（ID）、車両位置、インシデントの種類、優先度スコア、及び／又は同様のものなどのインシデントに関する基本情報を含む。この情報は、支援を必要とする車両100の支援要求ユニット11によって、別の車両150～158に、及び／又は、通信事業者を介した携帯電話のような、車両150～158の運転者のモバイルデバイス（図示せず）に、及び／又は、輸送システム用に特別に展開されたプライベート無線エリアネットワーク（WAN）を介して送信されてもよい。要求は、近接性および適切性に応じてユニキャスト送信モードにより単一の他の車両である受信者に、または複数の他の車両である受信者に、またはマルチキャスト送信モードによりすべての利用可能なアシスタント(支援者)に送信することができる。ここで、アシスタントは、好ましくは、他の車両150～158の運転者（オペレータまたはオペレータ-遠隔操作者）である。本開示による、要求(リクエスト)を送信するために、異なるリクエストポリシーが実施されてもよい。例えば、リクエストの単一のターゲット受信者（車両）を対象としてもよく、例えば、図３ａの例における最も関連性の高い支援者は、車両100の移動方向と反対の方向に最も近い支援者155、言い換えれば、既に乗っている支援者があればその人や同乗者、そうでなければ後続車両に乗る支援者、支援者が所定の時間後にリクエストを受け付けないとき、リクエストは後続の最も関連性の高い支援者に再割り当てされてもよい。また、ある車両に対する支援者の関連性の配置は、制御要求生成時に、要求を送信する自車両に対する支援者の近接度などの異なる要因を考慮してアルゴリズムで計算することもできる。そのために、支援者の位置は、支援者のモバイルデバイスのWiFi接続と各車両のWiFiルータを使用して決定することができる。また、制御要求を利用可能な支援者に効率的に分配するために、制御要求に優先度スコアを割り当てることもできる。

支援要求の受信者が遠隔操作で事件を解決できることを知った場合、支援要求の受信者がV2V遠隔操作を要請し、自車両100が受け入れた場合、起動する（S3、S4）。しかし、ステップS3において、遠隔操作で解決できるかどうかの答えが「YES」であれば、自車両100で事件が起きたかどうかの別の質問であるに進み、即ち、自車両100に運転者が乗っているか判断し(S5)、運転者が乗っている場合（S5でYES）、運転者が自ら現場支援を行ってもよい(S6)。しかし、自車両100に運転者がいないなどの理由で、他車両両150～158の運転者が現場支援を行う必要がある場合は、他車両両155が自車両100まで走行し（S7）、その後、現場支援を行う（S6）。さらに、図３ｂの点線矢印は、現場での支援の後、S4による遠隔操作を（一時的に）継続することも可能であることを示す。それ以外の場合は、再始動された自律走行S8で手順が継続される。

本開示による効率的な支援要求分配を実現するための１つの選択肢は、図４に示される、各車両100，150～158の記憶装置17またはリモートサーバ（図示せず）に管理テーブル20を提供することに依存してもよい。前記管理テーブル20は、システム内の各車両100，150～158のID21、その動作モード22、オペレータの有無に関するデータ23、及びオペレータの状態24について、各車両100，150～158に対してアクセス可能な概要を提供してもよい。さらに、C2V遠隔操作が追加的に提供される場合、管理テーブル20は、センター内のオペレータとそのステータス／稼働率に関するオペレータの状態25を含むこともできる。

図４の例で示したような管理テーブル20の情報を用いて、上述した優先／第一対象者決定方法は、図５によって示すような手続き的ステップ（P）を主に含む処理を行うことができる。すなわち、主に以下を含む処理が可能である。

各車両の位置データを受信し、自車両100と他の各車両150～158との間の各距離を計算し（ステップP１）、
利用可能なオペレータをチェックし、関連性、例えば近接／距離によってランク付けし（ステップP２）、
最も関連性の高い（例えば最も近い）利用可能なオペレータを決定して、決定したID21を有する該当車両150～158に要求を送信する（ステップP３）。

さらに、対象受信者の優先順位が記載された図示しない優先順位テーブルを設け、優先順位テーブルの情報も管理テーブルの情報と組み合わせて、または単独で利用できるようにしてもよい。例えば、優先順位テーブルが設けられている場合、図５のステップでは、距離／関連性の判定を行わず、優先順位テーブルの情報に基づいて、最も関連性の高い対象受信者を判定するようにしてもよい。

さらに、送信モードは、例えば、遠隔操作ECU11や車両100の他の構成要素によってケースバイケースで決定されてもよいし、システム管理者によって一定時間、例えば1日等、又は恒久的に予め決定されてもよく、例えば、ユニキャスト送信モードのみが使用されるようにしてもよい。また、送信モードの適応は、以下のような例を含む送信ポリシーに基づいて決定されてもよい。

ａ）遠隔操作と同様に現場での支援が必要⇒ユニキャストで、最も近くにいる支援者（または後続車の支援者）に要請を送信する。

ｂ）支援要求数が多く（例：1日・1台あたり100件以上）、遠隔操作や現場での支援も必要⇒最も適切な支援者をターゲットにした複数のユニキャストを行う。

ｃ）ほとんどの要望は遠隔操作で解決できる⇒マルチキャスト(人間の補助者を最小限にする)
ｄ）ほとんどの要求が遠隔操作で解決でき、システム規模が大きく（例：100台以上）、支援要求数が多い（例：1日・1台あたり100件以上）⇒マルチキャスト（人間の支援者数を最小限にする）、遠隔操作センターと組み合わせる。

ｅ）悪天候⇒より多くの支援者を配置し、より多くの支援要求に対応できるようにする。

＜支援要求の受付の運用＞
支援要求を受信すると、受信者／支援者は、自分の携帯端末を用いて、支援要求を受諾し、または拒否することができる。あるいは、支援要求はコックピットのディスプレイに表示され、コックピットまたはそのディスプレイを介して受諾または拒否することができる。要求が受理されると、支援者は、まだ存在しない場合は、車両（支援要求を送信したエゴ車両ではない）のコックピット102に行き、要求車両を制御する手順を実行する（なお、要求車両は、支援者が搭乗しているものと同じものであってもよい）。依頼車両100が支援者の乗っているものと同じでない場合、支援者は、自車のコックピット102でV2V遠隔操作手順を実行して、ディスプレイ105およびコックピット102を、制御要求を出した遠隔車両100に接続してもよい。その後、支援者は、V2V遠隔操作によって問題を解決してもよいし、（例えば、図３に提供される例に示されるように）現場支援を提供するために要求車両100に向かって運転してもよい。遠隔操作センターが存在する場合（図示せず）、アシスタント(支援者)は、別の車両150～158から、または遠隔操作センターから、遠隔車両を制御することができる。

＜支援要求の種類＞
自律走行に支障をきたすようなインシデントには様々な性質があり、それを分類することができる。しかし、本システムは柔軟性があり、支援要求の受信者は、インシデント／問題を克服するための最適なソリューションを選択することができる情報を受け取るので、分類されないインシデントも処理することができる。ただし、予め決められたインシデントを車両100の記憶装置17や本システムのリモートサーバに保存しておき、予め決められたインシデントが発生した場合の対応速度を高めておくことも可能である。

１）危険度の高い場所での事故
支援要求は、都心のような交通量の多い都市部、商業地、住宅地、農村部、人間活動の少ない田舎などで異なる可能性のある、実施された運転方針に従って生成されてもよい。高リスクエリアは、好ましくは、例えば、交通量が多い、又は多くの人が駆動経路を塞ぐ可能性がある等の理由により、運転操作が困難になるリスクの上昇に関連し得る。一例として、あるリスクスコアが満たされたときに、混雑した商業エリアで支援要求を生成することができ、かかるリスクスコアは、移動する自律車両100の前方の所定の距離範囲で経路を横断する動的オブジェクトの数、計画経路の近傍の動的オブジェクトの数、自律車両100の速度、および自律車両100の近傍の動的オブジェクトの相対速度等の関数であってもよい。このようなポリシーは、リスクスコア閾値に達したときに支援要求が生成されるように、リスクスコアアルゴリズム又は記憶空間に格納されたリスクスコアマップを通じて実行されてもよい。リスクスコアを計算する手順は、車両100がいるエリアに依存する。異なるエリアがマッピングされ、分類されてもよく、そこでは、自律車両は、GPS、GNSSなどのグローバルポジショニング、またはマップベースのローカリゼーションなどのローカルポジショニングのいずれかでマップに対してローカライズされてもよい。リスクスコアが計算されることに基づく手順は、路面電車、列車、シャトルバスなどの車両のタイプ、および展開領域のリスクのタイプも考慮することができる。

２）進路の遮断
自律走行車両100、150～158は、進路の遮断により停止することがある。この状況にどのように対応するかの方針は、路面電車、列車、シャトルバスなどの車両の種類と、地図上の現在地とを考慮して実施することができる。例えば、閉塞状態を解消させるためのリクエストを送信する前に、待ち時間をプログラムすることができる（例えば、進路を塞いでいる車など）。また、支援要求の生成は、ブロックされた自律走行車100、150～158が、例えば交差点で他の車両をもブロックしているかどうかに依存してもよい。

３）コンポーネントの誤動作
センサ101などのコンポーネントが正常に動作していない場合に発生することがある。例えば、重要なセンサ101が未知の物体（例えば、風によって運ばれるビニール袋）によって遮蔽され、このような事件は、事件に対する効率的な解決を可能にする本開示の利点を特に強調するものである。それぞれの支援要求につながる可能性のあるコンポーネントの誤動作の他の例は、コンポーネントが応答しないとき、2つの冗長デバイスまたはモジュールが対応する出力を提供しないとき、または遠隔操作に必要な通信レイテンシがある閾値を超えたときに発生する可能性がある。コンポーネント誤動作制御要求は、しばしば現場での支援を必要とするが、それにもかかわらず、支援者は、自分の現在の車両150～158が要求車両100に向かって自律的に走行する間、遠隔で問題に対処し始めることができ、又は要求車両100をブロックされた交差点から遠ざけるために最小限のV2V遠隔操作タスクを実行することができる。

支援要求ユニット11は、自車両のセンサデータ101、環境データ、又は位置データに基づいて、１）危険度の高い場所での事故、２）進路の遮断、３）コンポーネントの誤動作の何れの事故であるか事故の種類に応じて、現場支援又は車間遠隔操作運転のどちらが必要かの指示を生成し、発行する。好ましくは、車両100から発行される支援要求は、制御装置10またはそのサブユニットによってインシデントの種類を決定することが可能であった場合、決定されたインシデントの種類を示すインジケータを含む。

さらに、車両100、150～158がインシデントのタイプの自動判定を提供しない場合、またはタイプを判定できなかった場合、支援要求とともに送信された情報により、受信者はインシデントを判定し、問題を解決するための適切なアクションを選択することができる。したがって、車両100、150～158及び本明細書に記載のシステムが対処できない状況は存在しないため、インシデントに対する迅速な反応及び信頼性の高いサービスをいつでも確保することができる。

上述のように、予め定められたインシデントタイプの場合、特に支援要求（複数可）に鑑みて、予め定められた行動方針も存在し得る。このような予め定められたポリシーは、例えば、インシデントの検出および識別が、予期しないインシデントと比較して、制御装置10によってより迅速に処理され得るため、反応／応答速度を向上させることを可能にする。図６から図１２は、いくつかの起こり得るインシデントとそれを解決するための好ましい例示的なアクションに対処する、好ましいアクションポリシー、すなわち方法の例を示している。

図６は、マルチキャスト送信モードが支援要求の送信のために予め設定または選択されている場合の高リスクエリアの検出への対処方法の一例を示す図である。模式的に、図６は、7台の車両100、150～158（＃1～＃7）を含むシステムを示し、車両＃6は、高リスクエリア内またはその前にいることを検出し、したがってマルチキャストで他の車両（＃1～＃5、＃7）に支援要求を生成し、発行する。これは、図６において、各車両を指す破線矢印で描かれている。この例では、支援者となり得る2人のオペレータ／ドライバ、すなわち車両＃1及び＃5のドライバが、支援要求を受諾することによって返信する。このことは、車両＃6に戻る矢印で示されている。なお、車両＃7の運転者は不在／多忙であるが、システムは1回の受付のみを想定しているため、応答する必要はない。受諾を受けた後、またはそれ以上、支援要求したエゴ車両100は、それを受け入れた要求の受信者が、例えばこの場合、V2V遠隔操作によって支援を実行することを可能にする。図６の本例では、2人の運転者が支援要求を受け付けたので、1人を選択し、もう1人の運転者には受付を拒否したことを通知により知らせる。図６では、車両番号1のドライバが拒否したことの通知を受け取る。なお、選択は、所定のポリシーに基づいて自動化してもよく、例えば、受付返信が早い方を選択したり、最も近い他車両両150～158からの受付を選択したりしてもよい。車両＃5の運転手／オペレータに対してV2V遠隔操作が有効になった後、リモートサーバまたはシステムの各車両において、車両＃5の運転手が現在忙しいことを示し、車両＃6の状態を更新するために、管理テーブル、および必要に応じて設けられた優先順位テーブルが更新される。その後、V2V遠隔操作が直ちに開始され、車両#5の運転手／オペレータは、車両#5が自律走行を継続しながら、車両#6を高リスクエリア内で、遠隔操作でナビゲートすることができる。

他の例として、同じくハイリスクエリアのインシデントに関する図７を示すが、この例ではユニキャスト送信モードが使用される。この例では、図６の手順とは異なり、制御装置1または車両＃6のサブユニットが、車両IDの順位など、対象受信者の順位を示す図示しない優先順位テーブルを調べる。この図７の場合、最も優先順位の高い車両＃7は、管理テーブル20に運転者が忙しいことを表示しているため、2番目に優先順位が高く、利用可能な車両＃5が選択される。したがって、車両＃5が支援要求のユニキャスト対象受信者として決定され、次のステップで運転者がそれを受け入れるので、V2V遠隔操作を有効にして開始し、テーブル、特に管理テーブル20が更新される。

図８では、経路の遮断を検出し、車両150～158にマルチキャストでそれぞれの支援要求を送信した場合の例を示している。図６と同様に、2名のオペレータ／ドライバが要求を受け付け、1名のオペレータは多忙のため応答しない。他の車両150～158は、特に図示しない。次に、オプションとして、可能なアシスタント(支援者)のさらなる要求に応じて、支援者に正確な問題を判断するためのさらなる情報が提出され、彼／彼女は可能な最良の対応を判断することができるようになる。本実施例では、支援者は、問題がV2V遠隔操作によって解決され得ると決定するので、それに応じてV2V遠隔操作を可能にする車両＃6にそれぞれの遠隔操作可能要求が提出される。その後、前述と同様のさらなるステップを実行することができる。

図９は、マルチキャスト送信モードにおいて、現場支援につながる進路塞ぎ事故が発生した場合を示す図である。具体的には、車両＃6が経路の閉塞を検知し、その旨を表示した支援要求を生成し、他の車両に発行する。その後、図８と同様にフローが進むが、車両＃5の運転手は、支援要求データに含まれるセンサ情報を確認した結果、現地支援が望ましいと判断し、車両＃6にその旨を指示する。このとき、テーブル、特に管理テーブル20は、車両＃5の運転者の状態が変化したことなどの新たな情報を含むように更新される。車両＃6は、その後、現場支援を待つ。

図１０は、マルチキャストによる支援要求の発行とユニキャストによる現場支援の割り当てに依存した経路遮断事故処理の別の手順を示す。具体的には、全車両＃1～＃5及び＃7に対してマルチキャストで支援要求を送信する。すると、#1、#5の運転手は支援要求を受け付け、#7の運転手はビジー状態になる。その後、全車両のテーブル、すなわち管理テーブル20が更新され、センサ情報が車両＃1の運転手に送信される一方、＃5には受付拒否の旨が通知される。1の運転手は情報を確認し、現場支援を勧め、それが車両＃6に通知される。管理テーブル20を再度更新し、その後、車両内の優先順位テーブル（図示せず）に基づいて、どのオペレータが現場支援を引き継ぐべきかが決定される。最も近いものが最も速い場合があるので、最も近いものが選ばれる。優先順位表は、例えば、距離が予め決められている鉄道の状況において、最も近いオペレータの順位を示すものであってもよい。例えば、本実施例では、優先順位表は、＃7が、しかし忙しいということで1番目に含まれていてもよい。したがって、次のものが選択され、この例では、＃5である。そして、＃5の車両に対して現場応援要請が送信され、オペレータがそれを受理する。その後、テーブルが再び更新され、車両＃6は、支援者の到着を待つ。

さらに、図１１は、現場支援待ちの間に動作される可能性のある手順を示す。具体的には、車両#6は、車両#1の到着を待ち、その間に車両#1に更なるセンサ情報を送信してもよい。送信された情報は、自車両が障害物に向かって自律的に走行している間に、支援者に問題を認識させるのに役立つ可能性がある。なお、支援者の走行中にも障害物が解消される可能性がある（遠隔操作や交通状況の改善などの外部要因による）。その後、車両#6が車両#1に到着し、運転手が障害物を修理するなどして問題を乗り越え、その後自律走行を再開することができる。上記のステップの間、さらに、例えば図１１に示すように、異なる状況において、車両のテーブルが更新されることがある。

図１２は、部品の故障をユニキャストで送信する際の手順の流れを示す図である。車両＃6は、故障を検出した場合、記憶装置17またはリモートサーバに保存されている優先順位テーブル（図示せず）に従って、ユニキャストで支援要求を該当車両に送信する。支援要求の受信者である車両＃5のオペレータは、その要求を受け入れ、車両＃5の現場への移動を開始する。このように、異なる時間位置において、全車両について管理テーブル20が更新される。さらに、目的地に到着するまでの時間が長いため、搭乗しているオペレータの情報は、オペレータが到着する前に更新される。各車両は、全車両の情報を更新しておく。また、支援者の到着を待ってテーブルを更新することも可能である。さらに、車両#6が車両#5にセンサ情報を送りながら移動することで、車両#5が障害物に向かって自律的に走行しながら、支援者に障害物を周知させることができる。なお、支援者の移動中にも詰まりが解消される可能性がある。支援者の到着後、不具合を修正し、自律走行を再開することができる。

＜自律動作への復帰のための一般的な手順＞
支援者は、インシデント発生時に依頼車両100を操作するために必要な動作を行った後、そのためにコックピット102に必要な動作を行うことで、制御をデフォルトの自律運転に戻す。そのために、車両100が支援要求を送信した後、支援者のコックピット102に、自律運転が再び安全な制御を行う可能性があるときの信号を可視表示してもよい。この信号は、支援者が自律走行車両100に制御を戻す判断をするのに役立つ。アプリケーションによっては、支援者が制御を行うのを待っている要求車両100は、制御要求が不要になった（例えば、ブロックされた経路が解決された）場合に制御要求をキャンセルし、自律運転を継続することができる。

例えば本明細書に記載されたシステムは、異なる車両及びネットワークによって形成されてもよいことに留意されたい、しかしながら、システム内にグループ化され、通信可能に接続された車両100、150～158の概略配置は、図３ｂによって示されている。

本開示案は、特に、車両がより効率的に運用され、サービス品質を向上させるために障害の頻度と期間を減少させるといった技術的な利点を有する。人間のオペレータは、現場での支援が必要な場合、その現在の車両150～158を使用して、車両100に向かって移動することができる。

さらに、多数の車両100、150～158（V）は、より良い効率と低い運用コストのために、O＜＝Vである多数のオペレータ／遠隔操作者（O）によって操作され得る。従来の運転は、法律で義務付けられている場合、または天候が悪い場合などには可能である。遠隔操作と物理的な作業を組み合わせた、より快適な作業負荷（自動化レベルに応じて、退屈/眠気を軽減するためにより多様な作業をオペレータに割り当てることができる）。オペレータ・遠隔操作者のトレーニングは、従来の運転と同様である。オペレータは常に現場にいて、状況を把握しているため、より迅速で適切な現場支援が可能である。）遠隔操作センターが不要なため、システムのコスト（設備、ハードウェア、メンテナンスに関連する）が削減され、セキュリティが向上する（集中型ではなく分散型システム）。ただし、このようなセンターは、本発明の範囲を狭めることなく提案するソリューションに統合することができる。例えば、遠隔操作センターまたはコントロールセンターは、数百台の車両を有する大規模輸送システム（例えば、パリや東京などの大都市の公共交通機関）に対する追加の安全および管理層として統合することができ、支援者は待機室（コントロールセンター）にいることができ、および／または他の車両からおよび遠隔操作センターから車両を遠隔操作することもできる。

当業者によって理解されるように、本開示は、本明細書上および添付の図に記載されているように、方法（例えば、コンピュータ実装プロセスまたは任意の他のプロセス）、装置（デバイス、マシン、システム、コンピュータプログラム製品、および／または任意の他の装置を含む）、または前述の組み合わせとして具現化されてもよい。本開示の態様／例は、完全にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または「システム」と呼ばれ得るソフトウェアおよびハードウェアの態様の組合せであってよい。さらに、本開示は、媒体に具現化されたコンピュータ実行可能なプログラムコードを有するコンピュータ可読媒体上のコンピュータプログラム製品の形態をとってもよい。

図面では、２つ以上のエンティティが関与する通信、転送、または他のアクティビティを表すために矢印が使用される場合があることに留意されたい。両端矢印が存在する場合、一般に、活動は両方向に発生する可能性があることを示すが（例えば、一方の方向のコマンド／要求と他方の方向の対応する返信、またはいずれかのエンティティによって開始されるピアツーピア通信）、いくつかの状況では、活動は必ずしも両方向に発生しない可能性がある。

シングルエンド矢印は、一般に、排他的または支配的に一方向の活動を示すが、特定の状況において、そのような方向性の活動は、実際には両方向の活動（例えば、送信者から受信者へのメッセージおよび受信者から送信者への確認応答、または転送前の接続の確立および転送後の接続の終了）を含むことができることに注意されたい。したがって、特定の活動を表すために特定の図面で使用される矢印のタイプは例示的なものであり、限定的なものと見なしてはならない。

本開示は、方法および装置のフローチャート図および／またはブロック図を参照して、ならびに方法および／または装置によって生成されるグラフィカルユーザインターフェースの多数のサンプルビューを参照して説明され得る。フローチャート図および／またはブロック図の各ブロック、および／またはフローチャート図および／またはブロック図におけるブロックの組み合わせ、ならびにグラフィカルユーザインターフェースは、コンピュータ実行可能なプログラムコードによって実装できることが理解されよう。

コンピュータ実行可能なプログラムコードは、汎用コンピュータ、特殊用途コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供され、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行されるプログラムコードが、フローチャート、図、および／または書面による説明で指定された機能／行為／出力を実施するための手段を作成するように、特定の機械を製造することができる。

コンピュータ実行可能なプログラムコードは、コンピュータまたは他のプログラム可能なデータ処理装置に特定の方法で機能するように指示することができるコンピュータ可読メモリに格納されてもよく、コンピュータ可読メモリに格納されたプログラムコードが、フローチャート、ブロック図ブロック、図、および／または書面による説明で指定された機能／行為／出力を実装する指示手段を含む製造物品を生成するようにしてもよい。

コンピュータ実行可能なプログラムコードは、コンピュータまたは他のプログラム可能なデータ処理装置にロードされて、コンピュータまたは他のプログラム可能な装置上で実行されるプログラムコードが、フローチャート、図、および／または書面による説明で指定された機能／行為／出力を実施するためのステップを提供するようなコンピュータ実装のプロセスを生成するための一連の動作ステップを実行させることも可能である。代替的に、コンピュータプログラム実装ステップまたは行為は、本開示の実施形態を実行するために、オペレータまたは人間が実装するステップまたは行為と組み合わされてもよい。

「サーバ」及び「プロセッサ」などの用語は、本開示の特定の態様で使用され得るデバイスを説明するために本明細書で使用され得、文脈が他に要求しない限り、本開示を任意の特定のデバイスタイプに限定するように解釈されるべきではないことに留意されたい。したがって、デバイスは、限定されないが、ブリッジ、ルータ、ブリッジルータ（brouter）、スイッチ、ノード、サーバ、コンピュータ、アプライアンス、または他のタイプのデバイスを含んでもよい。このようなデバイスは、典型的には、通信ネットワーク上で通信するための１つ以上のネットワークインタフェースと、デバイス機能を実行するために適宜構成されたプロセッサ（例えば、メモリと他の周辺機器及び／又はアプリケーション固有のハードウェアを備えたマイクロプロセッサ）とを含む。

通信ネットワークは、一般に、公衆ネットワークおよび／またはプライベートネットワークを含み、ローカルエリア、ワイドエリア、メトロポリタンエリア、ストレージ、および／または他のタイプのネットワークを含み、アナログ技術、デジタル技術、光学技術、無線技術（例えば、Bluetooth）、ネットワーク技術、およびインターネットワーキング技術（これらに限定されない）を含む通信技術を使用することができる。

また、デバイスは、通信プロトコルおよびメッセージ（例えば、デバイスによって作成、送信、受信、保存、および／または処理されたメッセージ）を使用してもよく、かかるメッセージは、通信ネットワークまたは媒体によって伝達されてもよいことに留意する必要がある。

文脈が特に要求しない限り、本開示は、任意の特定の通信メッセージタイプ、通信メッセージフォーマット、又は通信プロトコルに限定されるものと解釈されるべきではない。したがって、通信メッセージは、一般に、限定されないが、フレーム、パケット、データグラム、ユーザデータグラム、セル、又は他のタイプの通信メッセージを含み得る。

文脈上他に必要とされない限り、特定の通信プロトコルへの言及は例示であり、代替案は、適宜、かかる通信プロトコルの変形（例えば、随時行われるプロトコルの修正または拡張）または既知もしくは将来開発されるいずれかの他のプロトコルを採用してもよいと理解されるべきである。

また、論理フローは、本開示の様々な態様を示すために本明細書に記載されてもよく、本開示を任意の特定の論理フローまたは論理実装に限定すると解釈すべきではないことに留意されたい。記述された論理は、全体的な結果を変えることなく、またはそうでなければ本開示の真の範囲から逸脱することなく、異なる論理ブロック（例えば、プログラム、モジュール、機能、またはサブルーチン）に分割されてもよい。

多くの場合、論理要素は、全体的な結果を変えることなく、またはそうでなければ本開示の範囲から逸脱することなく、追加、変更、省略、異なる順序で実行、または異なる論理構成（例えば、論理ゲート、ループプリミティブ、条件論理、および他の論理構成）を使用して実装されてもよい。

本開示は、グラフィカルプロセッシングユニットだけでなく、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）で使用するためのコンピュータ・プログラム・ロジック、プログラマブルロジックデバイスで使用するためのプログラマブルロジック（例えば。プログラマブル・ゲート・アレイ（FPGA）等のPLD）、ディスクリート部品、集積回路（ASIC）、またはそれらの組み合わせを含む他の手段。説明した機能の一部または全部を実装するコンピュータ・プログラム・ロジックは、典型的には、コンピュータ実行可能な形式に変換され、コンピュータ可読媒体にそのように格納され、オペレーティングシステムの制御下でマイクロプロセッサによって実行されるコンピュータ・プログラム命令のセットとして実装される。説明した機能の一部または全部を実装するハードウェアベースのロジックは、１つまたは複数の適切に構成されたFPGAを使用して実装することができる。

本明細書で先に説明した機能の全部または一部を実装するコンピュータプログラム論理は、ソースコード形式、コンピュータ実行形式、および様々な中間形式（例えば、アセンブラ、コンパイラ、リンカ、またはロケータによって生成される形式）を含むが、これらに限定されない様々な形式で具現化することができる。

ソースコードは、様々なオペレーティングシステムまたは動作環境と共に使用するために、様々なプログラミング言語（例えば、オブジェクトコード、アセンブリ言語、またはFortran、python、C、C++、JAVA、JavaScriptまたはHTMLなどの高位言語、JAVA（登録商標）のいずれかで実装される一連のコンピュータプログラム命令を含むことができる。ソースコードは、様々なデータ構造および通信メッセージを定義し、使用することができる。ソースコードは、（例えば、インタプリタを介して）コンピュータ実行可能な形態であってもよいし、ソースコードを（例えば、トランスレータ、アセンブラ、またはコンパイラを介して）コンピュータ実行可能な形態に変換することも可能である。

本開示の態様の動作を遂行するためのコンピュータ実行可能なプログラムコードは、Java、Perl、Smalltalk、C++などのオブジェクト指向、スクリプト化または非スクリプト化プログラミング言語において書かれてもよい。しかしながら、本開示の態様の動作を遂行するためのコンピュータプログラムコードはまた、「C」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語で書かれてもよい。

本明細書で先に説明した機能の全部または一部を実装するコンピュータプログラム論理は、単一のプロセッサ上で異なる時間に実行されてもよく（例えば、同時実行）、または複数のプロセッサ上で同じ時間または異なる時間に実行されてもよく、単一のオペレーティングシステムプロセス／スレッドの下で実行しても、異なるオペレーティングシステムプロセス／スレッドの下で実行してもよい。

したがって、「コンピュータプロセス」という用語は、異なるコンピュータプロセスが同じプロセッサで実行されるか異なるプロセッサで実行されるかにかかわらず、また異なるコンピュータプロセスが同じオペレーティングシステムのプロセス/スレッドで実行されるか異なるオペレーティングシステムのプロセス/スレッドで実行されるかにかかわらず、コンピュータプログラム命令のセットの実行を一般的に指す。

コンピュータプログラムは、半導体記憶装置（例えば、RAM、ROM、PROM、EEPROM、Flash-Programmable RAM）、磁気記憶装置（例えば、ディスケット、固定ディスク）、光記憶装置（例えば、CD-ROM）、PCカード（例えば、PCMCIAカード）などの有形記憶媒体に永久的または一時的に任意の形態（例えば、ソースコード形態、コンピュータ実行形態または中間形態）で固定されてもよい。

コンピュータプログラムは、アナログ技術、デジタル技術、光技術、無線技術（例えば、Bluetooth）、ネットワーク技術、およびインターネットワーキング技術などの様々な通信技術のいずれかを用いてコンピュータに送信可能な信号に任意の形態で固定されてもよい。

コンピュータ・プログラムは、印刷物または電子文書を添付した取り外し可能な記憶媒体（例えば、シュリンクされたソフトウェア）として、コンピュータ・システムにプリロードされて（例えば、システムROMまたは固定ディスクに）、または通信システム（例えば、インターネットまたはWorld Wide Web）上でサーバまたは電子掲示板から配布されるなど、任意の形態で配布することが可能である。

本書で既に説明した機能のすべてまたは一部を実装するハードウェアロジック（プログラマブルロジックデバイスで使用するプログラマブルロジックを含む）は、従来の手作業で設計してもよいし、コンピュータ支援設計（CAD）、ハードウェア記述言語（VHDLまたはAHDLなど）、PLDプログラミング言語（PALASM、ABEL、CUPLなど）などの各種ツールを用いて電子的に設計、キャプチャ、シミュレーション、文書化することが可能である。

任意の適切なコンピュータ可読媒体を利用することができる。コンピュータ可読媒体は、例えば、電子、磁気、光学、電磁、赤外線、または半導体のシステム、装置、デバイス、または媒体であってもよいが、これらに限定されるものではない。

コンピュータ可読媒体のより具体的な例としては、1本以上のワイヤを有する電気接続、またはポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（RAM）、読み取り専用メモリ（ROM）、消去可能プログラム可能読み取り専用メモリ（EPROMまたはフラッシュメモリ）、コンパクトディスク読み取り専用メモリ（CD-ROM）などの有形記憶装置、または他の光または磁気記憶装置があるが、これには限定されない。

プログラマブルロジックは、半導体メモリ装置（RAM、ROM、PROM、EEPROM、Flash-Programmable RAMなど）、磁気メモリ装置（ディスケット、固定ディスクなど）、光メモリ装置（CD-ROMなど）などの有形記憶媒体に永久的または一時的に固定することができる。

プログラマブルロジックは、アナログ技術、デジタル技術、光技術、無線技術（例えば、Bluetooth）、ネットワーキング技術、およびインターネットワーキング技術など、様々な通信技術のいずれかを使用してコンピュータに送信可能な信号に固定されてもよい。

プログラム可能なロジックは、付属の印刷または電子文書（例えば、シュリンクされたソフトウェア）を備えた取り外し可能な記憶媒体として配布されてもよく、コンピュータシステムにプリロードされてもよく（例えば、システムROMまたは固定ディスクに）、または通信システム（例えば、インターネットまたはワールドワイドウェブ）上でサーバまたは電子掲示板から配布されてもよい。もちろん、本開示のいくつかの実施形態は、ソフトウェア（例えば、コンピュータプログラム製品）およびハードウェアの両方の組み合わせとして実装されてもよい。本開示のさらに他の態様は、完全にハードウェアとして、または完全にソフトウェアとして実装される。

特定の例示的な態様を説明し、添付の図面に示したが、そのような実施形態は、単に広い開示を例示するものであり、制限するものではないこと、および、上記の段落に規定されたものに加えて、様々な他の変更、組み合わせ、省略、修正および置換が可能であるので、本開示の態様は、図示および説明した特定の構造および配置に制限されないことが理解されるものである。

当業者であれば、今説明した態様及び実施例の様々な適応、修正、及び／又は組み合わせが構成され得ることを理解するであろう。したがって、添付の特許請求の範囲の範囲内で、本開示は、本明細書に具体的に記載された以外の方法で実施され得ることが理解されよう。例えば、明示的に別段の記載がない限り、本明細書に記載のプロセスのステップは、本明細書に記載のものとは異なる順序で実行されてもよく、１つまたは複数のステップが組み合わされ、分割され、または同時に実行されてもよい。当業者はまた、本開示に鑑みて、本明細書に記載された本開示の異なる態様又は実施例が組み合わされて、本開示の他の態様又は実施例を形成してもよいことを理解するであろう。

１：制御装置
１０：制御装置／遠隔操作制御装置
１１：支援要求ユニット
１２：自律走行制御ユニット
１３－１６：その他の電子制御ユニット（複数可）
１７：記憶装置
２０：管理テーブル
２１：車両ID（データ）
２２：動作モード（データ）
２３：オペレータの存在（データ）
２４：オペレータの状態（データ）
２５：オペレータの状態
１００：車両
１０１：センサ
１０２：コックピット
１０３：通信装置
１０４：制御装置または駆動装置
１０５：ディスプレイ
１５０－１５８：その他の車両（複数可）

Claims (10)

1. 遠隔操作可能な複数の車両により構成される車両用遠隔操作システムであって、
   前記複数の車両は、
   自律走行モード、手動走行モード、及び車間遠隔操作走行モードを提供する制御装置を備え、
   前記自律走行モードでは、前記車両の走行が自動的に制御可能であり、前記手動走行モードでは、前記車両の走行が運転者によって制御可能であり、前記車間遠隔操作走行モードでは、前記車両の走行が他の車両に位置する運転者によって制御可能であり、
   前記車両は、さらに、自律走行モードの使用を妨げる事象を検出し、該事象を検出した場合に、通信装置を介して他の車両の運転者に支援要求を送信するように構成された支援要求部を備え、
   前記支援要求部は、前記車両のセンサデータ、環境データ、又は位置データに基づいて判定した事故の種類に応じて、現場支援又は車間遠隔操作運転のどちらが必要かの指示を生成し、
   前記支援要求部により進路遮断状況が判定された場合、前記支援要求部は、前記他の車両に現場支援又は車間遠隔操作運転のどちらが必要かの指示を含む支援要求を、送信し、
   前記支援要求部により高リスク運転領域が判定された場合、前記支援要求部は、車間遠隔操作運転を要求する旨の指示を含む前記支援要求を、送信し、
   前記支援要求部により前記車両の部品の故障が判定された場合、前記支援要求部は、現場支援を依頼する旨の指示を含む前記支援要求を、送信し、
   前記支援要求部により悪天候であると判定された場合、前記支援要求部は、車間遠隔操作走行が望ましい旨の指示を含む前記支援要求を、送信する、車両用遠隔操作システム。
2. 請求項１に記載の車両用遠隔操作システムにおいて、
   前記車両の前記支援要求部は、
   ユニキャストまたはマルチキャストのいずれかで支援要求を発行し、ユニキャストまたはマルチキャストの送信モードは、所定の送信ポリシーおよび／または記憶空間に記憶される検出されたインシデントの種類に基づいて選択される、車両用遠隔操作システム。
3. 請求項２に記載の車両用遠隔操作システムにおいて、
   前記車両は、前記記憶空間に記憶され、自車両及び他の車両について、車両識別情報、運転モード情報、運転者搭載情報、及び運転者状態情報を含むように設けられた管理テーブルをさらに有し、
   前記支援要求部は、前記管理テーブルの情報と、各他の車両の位置情報とに基づいて、前記支援要求を送信するように構成される、車両用遠隔操作システム。
4. 請求項３に記載の車両用遠隔操作システムにおいて、
   前記車両は、前記管理テーブルに、支援要求可能な受信者の優先度情報を含む優先順位テーブルを備え、前記支援要求をユニキャストで送信する場合、前記優先順位テーブルにおいて最も高い優先度を有する受信者に支援要求を送信する、車両用遠隔操作システム。
5. 請求項４に記載の車両用遠隔操作システムにおいて、
   前記管理テーブルおよび／または前記優先順位テーブルは、予め設定された変更イベントが発生した場合に、それぞれ更新される、車両用遠隔操作システム。
6. 請求項５に記載の車両用遠隔操作システムにおいて、
   前記他の車両は、データ交換のために運転者のモバイルデバイスと接続するように構成されたインターフェースをさらに含み、前記運転者のモバイルデバイスが前記インターフェースに接続されると、前記モバイルデバイスの画面上に支援要求が表示される、車両用遠隔操作システム。
7. 請求項５に記載の車両用遠隔操作システムにおいて、
   前記他の車両の制御装置は、
   前記管理テーブルが前記車両のオペレータの状態を示していない場合、前記他の車両の支援要求に応答して拒否コマンドを送信する車両用遠隔操作システム。
8. 請求項５に記載の車両用遠隔操作システムにおいて、
   前記車両の制御装置は、前記管理テーブルが前記車両のオペレータの状態を示していない場合、前記他の車両の支援要求に応答して拒否コマンドを送信する、車両用遠隔操作システム。
9. 請求項６に記載の車両用遠隔操作システムにおいて、
   前記複数の車両のうち一部の車両には運転手が存在し、他の車両には運転手が存在せず、前記複数の車両は、ネットワークを介して互いに通信可能に接続される、車両用遠隔操作システム。
10. 請求項６に記載の車両用遠隔操作システムにおいて、
    前記車両用遠隔操作システムは、前記複数の車両の1つ以上の遠隔操作を行う遠隔操作センターを含み、前記管理テーブルは、前記遠隔操作センターにおけるオペレータの状態を示す別のエントリを含む、車両用遠隔操作システム。

Images