JP2023135614A - 処理方法、運転システム、処理プログラム - Google Patents

Abstract

【課題】他道路ユーザの対応力向上に貢献する処理方法の提供。【解決手段】運転システムにおいてホスト移動体の運転に関する処理を遂行するために、プロセッサにより実行される処理方法は、運転システムにより緊急操作されたホスト移動体の当該緊急操作からの運転復帰を、判断することと、ホスト移動体外に運転復帰を、報知することとを、含む。【選択図】図４

Description

本開示は、運転システムにおいてホスト移動体の運転に関する処理を遂行するための技術に、関する。

特許文献１に開示される技術では、ホスト移動体としての車両が運転システムの緊急操作により停止した後、解除スイッチが押されると、当該車両が走行を再開可能となっている。

特許第６３３１９７５号公報

しかし、特許文献１に開示される技術では、緊急操作された車両が急に復帰して走行を再開すると、当該復帰車両外の他道路ユーザにとって適切に対応することは、困難となるおそれがあった。

本開示の課題は、他道路ユーザの対応力向上に貢献する処理方法を、提供することにある。本開示の別の課題は、他道路ユーザの対応力向上に貢献する運転システムを、提供することにある。本開示のさらに別の課題は、他道路ユーザの対応力向上に貢献する処理プログラムを、提供することにある。

以下、課題を解決するための本開示の技術的手段について、説明する。尚、特許請求の範囲及び本欄に記載された括弧内の符号は、後に詳述する実施形態に記載された具体的手段との対応関係を示すものであり、本開示の技術的範囲を限定するものではない。

本開示の第一態様は、
運転システム（ＤＳ）においてホスト移動体（２）の運転に関する処理を遂行するために、プロセッサ（１２）により実行される処理方法であって、
運転システムにより緊急操作されたホスト移動体の当該緊急操作からの運転復帰を、判断することと、
ホスト移動体外に運転復帰を、報知することとを、含む。

本開示の第二態様は、
プロセッサ（１２）を有し、ホスト移動体（２）の運転に関する処理を遂行する運転システム（ＤＳ）であって、
当該運転システムにより緊急操作されたホスト移動体の当該緊急操作からの運転復帰を、判断することと、
ホスト移動体外に運転復帰を、報知することとを、実行するように構成される。

本開示の第三態様は、
運転システム（ＤＳ）においてホスト移動体（２）の運転に関する処理を遂行するために記憶媒体（１０）に記憶され、プロセッサ（１２）により実行される命令を含む処理プログラムであって、
命令は、
運転システムにより緊急操作されたホスト移動体の当該緊急操作からの運転復帰を、判断させることと、
ホスト移動体外に運転復帰を、報知させることとを、含む。

これら第一～第三態様では、運転システムにより緊急操作されたホスト移動体の当該緊急操作からの運転復帰が、判断される。そこで第一～第三態様によると、ホスト移動体外には、ホスト移動体の運転復帰が報知されることになる。これによれば、報知されるホスト移動体の外部環境に存在する他道路ユーザは、緊急操作されたホスト移動体の運転復帰に対して、当該報知に応じた対応を採ることができる。故に、他道路ユーザの対応力向上に貢献することが可能となる。

第一実施形態による運転システムの物理アーキテクチャを示すブロック図である。 第一実施形態の適用されるホスト車両の走行環境を示す模式図である。 第一実施形態による運転システムの機能アーキテクチャを示すブロック図である。 第一実施形態による処理フローを示すフローチャートである。 第二実施形態による処理フローを示すフローチャートである。 第三実施形態による処理フローを示すフローチャートである。 第四実施形態による処理フローを示すフローチャートである。 第五実施形態による処理フローを示すフローチャートである。 第六実施形態による処理フローを示すフローチャートである。 第六実施形態の適用されるホスト車両の走行環境を示す模式図である。 第六実施形態を第二実施形態に適用した変形例による処理フローを示すフローチャートである。

以下、本開示の実施形態を図面に基づき複数説明する。尚、各実施形態において対応する構成要素には同一の符号を付すことにより、重複する説明を省略する場合がある。また、各実施形態において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態の構成を適用することができる。さらに、各実施形態の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態の構成同士を部分的に組み合わせることができる。

（第一実施形態）
図１に示される第一実施形態の運転システムＤＳは、ホスト移動体の運転に関する処理（以下、運転処理と称する）を遂行するために、処理システム１を含んで構成される。運転システムＤＳの一部又は全部は、ホスト移動体に搭載される。

運転システムＤＳにおいて運転処理の対象とされるホスト移動体は、図２に示されるホスト車両２である。ホスト車両２は、例えば自動車、又はトラック等の自動運転を実行可能な道路ユーザ（road user）である。ホスト車両２は、自車両（ego-vehicle）と称されてもよい。ホスト車両２における運転は、全ての動的運転タスク（dynamic driving task：ＤＤＴ）のうち、運転席上の乗員であるドライバが行なうタスク範囲に応じて、レベル分けされる。ここで、自動運転レベルに応じたホスト車両２の手動操作によってＤＤＴを担うことの可能なドライバは、車両オペレータ（vehicle operator）であって、車両ユーザ（vehicle user）であるともいえる。

自動運転レベルは、例えばＳＡＥ Ｊ３０１６等に規定される。具体的にレベル０～２では、ドライバがＤＤＴの一部又は全部を行なう。レベル０～２は、いわゆる手動運転に分類されてもよい。レベル０は、運転が自動化されていないことを示す。レベル１は、ドライバを運転システムＤＳが支援することを示す。レベル２は、部分的に運転が自動化されたことを示す。レベル３以上では、運転システムＤＳがエンゲージされている間、当該運転システムＤＳはＤＤＴの全部を行なう。レベル３～５は、いわゆる自動運転に分類されてもよい。レベル３以上の運転を実行可能な運転システムＤＳは、自動運転システム（automated driving system）と称されてもよい。レベル３は、条件付きで運転が自動化されたことを示す。レベル４は、高度に運転が自動化されたことを示す。レベル５は、完全に運転が自動化されたことを示す。レベル３以上の運転を実行不能、且つレベル１及び２のうち少なくとも一方の運転を実行可能な運転システムＤＳは、運転支援システムと称されてもよい。以下では、実現可能な最大の自動運転レベルを特定する事情がない場合、自動運転システム又は運転支援システムが運転システムＤＳに含まれているものとする。

このようなホスト車両２に対して他道路ユーザ（other road user）３は、ホスト車両２の走行する外部環境に存在する、ホスト車両２以外の道路ユーザである。他道路ユーザ３には、例えば自動車、トラック、バイク、及び自転車といった非脆弱な道路ユーザと、歩行者といった脆弱な道路ユーザとが、含まれる。他道路ユーザ３にはさらに、動物が含まれてもよい。

図１に示される物理アーキテクチャにおいて運転システムＤＳは、アクチュエータ系４、センサ系５、通信系６、地図データベース（data base：ＤＢ）７、情報インタフェース（interface：ＩＦ）系８、及び処理システム１を物理的構成要素としている。但し、運転システムＤＳは、自己の物理的構成要素としては少なくとも処理システム１を含んでいればよく、アクチュエータ系４、センサ系５、通信系６、地図ＤＢ７、及び情報ＩＦ系８に属する物理的構成要素のうち少なくとも一種類としては、ホスト車両２に属する物理的構成要素が代替されてもよい。

アクチュエータ系４は、入力される制御信号に基づきホスト車両２の運転を制御可能に、構成されている。アクチュエータ系４は、例えば内燃機関、及びモータジェネレータモータ等のうち、少なくとも一種類のパワートレインアクチェータであってもよい。アクチュエータ系４は、例えばブレーキユニット等といった、少なくとも一種類の制動アクチュエータであってもよい。アクチュエータ系４は、例えばパワーステアリングユニット等といった、少なくとも一種類の操舵アクチュエータであってもよい。

センサ系５は、ホスト車両２の外部環境及び内界環境を検出することにより、運転システムＤＳにより利用可能なセンサデータを取得する。そのためにセンサ系５には、外部環境センサ５０と内部環境センサ５２とが含まれている。

外部環境センサ５０は、ホスト車両２の外部環境に存在する物標を、検出してもよい。物標検出タイプの外部環境センサ５０は、例えばカメラ、ＬｉＤＡＲ（light detection and ranging / laser imaging detection and ranging）、レーザレーダ、ミリ波レーダ、及び超音波ソナー等のうち、少なくとも一種類である。物標検出タイプの外部環境センサ５０は、典型的にホスト車両２の前方、側方、及び後方の各方向をセンシング可能に、複数種類を組み合わされて実装される。外部環境センサ５０は、ホスト車両２の外部環境における大気の状態を、検出してもよい。大気検出タイプの外部環境センサ５０は、例えば外気温センサ、及び湿度センサ等のうち、少なくとも一種類である。

内部環境センサ５２は、ホスト車両２の内部環境において車両運動に関する特定の物理量（以下、運動物理量と称する）を、検出してもよい。運動物理量検出タイプの内部環境センサ５２は、例えば速度センサ、加速度センサ、及びジャイロセンサ等のうち、少なくとも一種類である。内部環境センサ５２は、ホスト車両２の内部環境に搭乗する乗員の状態を、検出してもよい。乗員検出タイプの内部環境センサ５２は、例えばアクチュエータセンサ、ドライバーステータスモニター（登録商標）、生体センサ、着座センサ、及び車内機器センサ等のうち、少なくとも一種類である。ここでアクチュエータセンサとしては、ホスト車両２のアクチュエータ系４に関する乗員の操作状態を検出する、例えば起動スイッチ、アクセルセンサ、ブレーキサンサ、及び操舵センサ等のうち、少なくとも一種類が挙げられる。

通信系６は、運転システムＤＳにおいて利用可能な通信データを、無線通信により取得する。通信系６は、ホスト車両２の外部環境に存在するＧＮＳＳ（global navigation satellite system）の人工衛星から、測位信号を受信してもよい。測位タイプの通信系６は、例えばＧＮＳＳ受信機等である。通信系６は、ホスト車両２の外部環境に存在するＶ２Ｘシステムとの間において、通信信号を送受信してもよい。Ｖ２Ｘタイプの通信系６は、例えばＤＳＲＣ（dedicated short range communications）通信機、及びセルラＶ２Ｘ（C-V2X）通信機等のうち、少なくとも一種類である。ここでＶ２Ｘシステムとの通信としては、他道路ユーザ３である他車両の通信システムとの通信（Ｖ２Ｖ）、信号機に設置された通信機の如きインフラ設備との通信（Ｖ２Ｉ）、他道路ユーザ３である歩行者のモバイル端末との通信（Ｖ２Ｐ）、及びクラウドネットワーク又はメッシュネットワークとの通信（Ｖ２Ｎ）等のうち、少なくとも一種類が挙げられる。通信系６は、ホスト車両２の内部環境に存在するモバイル端末との間において、通信信号を送受信してもよい。端末通信タイプの通信系６は、例えばブルートゥース（Bluetooth：登録商標）機器、Ｗｉ－Ｆｉ（登録商標）機器、及び赤外線通信機器等のうち、少なくとも一種類である。

地図ＤＢ７は、運転システムＤＳにより利用可能な地図データを、記憶する。地図ＤＢ７は、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）を含んで構成される。地図ＤＢ７は、自己位置を含んだホスト車両２の自己状態量を推定するロケータの、ＤＢであってもよい。地図ＤＢは、ホスト車両２の走行経路をナビゲートするナビゲーションユニットの、ＤＢであってもよい。地図ＤＢ７は、複数種類のＤＢの組み合わせにより、構築されてもよい。

地図ＤＢ７は、例えばＶ２Ｘタイプの通信系６を介した外部センタとの通信等により、最新の地図データを取得して記憶する。地図データは、ホスト車両２の走行環境を表すデータとして、二次元又は三次元にデータ化されている。三次元の地図データとしては、高精度地図のデジタルデータが採用されてもよい。地図データは、例えば道路構造の位置座標、形状、及び路面状態等のうち、少なくとも一種類を表した道路データを含んでいてもよい。地図データは、例えば道路に付属する道路標識、道路表示、及び区画線の、位置座標並びに形状等のうち、少なくとも一種類を表した標示データを含んでいてもよい。地図データに含まれる標示データは、ランドマークのうち、例えば交通標識、矢印マーキング、車線マーキング、停止線、方向標識、ランドマークビーコン、長方形標識、ビジネス標識、又は道路のラインパターン変化等を表していてもよい。地図データは、例えば道路に面する建造物及び信号機の、位置座標並びに形状等のうち、少なくとも一種類を表した構造物データを含んでいてもよい。地図データに含まれる標示データは、ランドマークのうち、例えば街灯、道路のエッジ、反射板、ポール、又は道路標識の裏側等を表していてもよい。

情報ＩＦ系８は、ホスト車両２のドライバを含む乗員と、運転システムＤＳとの間において運転処理に関連する報知情報の伝達を、媒介する。そのために情報ＩＦ系８には、ＨＭＩ（human machine interface）機器８０が含まれている。

ＨＭＩ機器８０は、ホスト車両２における乗員の意図を運転システムＤＳへ入力するための操作を検出可能に、構成されていてもよい。操作検出タイプのＨＭＩ機器８０は、例えばプッシュスイッチ、レバースイッチ、及びタッチパネル等のうち、少なくとも一種類である。操作検出タイプのＨＭＩ機器８０は、センサ系５のうち内部環境センサ５２としてのアクチュエータセンサ等により、代替されてもよい。ＨＭＩ機器８０は、ホスト車両２における乗員の意図を運転システムＤＳへ入力するためのジェスチャーを検出可能に、構成されていてもよい。ジェスチャー検出タイプのＨＭＩ機器８０は、センサ系５のうち内部環境センサ５２としてのドライバーステータスモニター等により、代替されてもよい。

ＨＭＩ機器８０は、ホスト車両２において乗員の視覚を刺激することより、報知情報を提示してもよい。視覚情報提示タイプのＨＭＩ機器８０は、例えばＨＵＤ（head-up display）、ＣＩＤ（center information display）、ＭＦＤ（multi function display）、コンビネーションメータ、ナビゲーションユニット、及びイルミネーションユニット等のうち、少なくとも一種類である。ＨＭＩ機器８０は、乗員の聴覚を刺激することにより、報知情報を提示してもよい。聴覚情報提示タイプのＨＭＩ機器８０は、例えばスピーカ、ブザー、及びバイブレーションユニット等のうち、少なくとも一種類である。ＨＭＩ機器８０は、乗員の皮膚感覚を刺激することにより、報知情報を提示してもよい。皮膚感覚情報提示タイプのＨＭＩ機器８０は、例えばステアリングホイールのバイブレーションユニット、運転席のバイブレーションユニット、ステアリングホイールの反力ユニット、アクセルペダルの反力ユニット、ブレーキペダルの反力ユニット、及び空調ユニット等のうち、少なくとも一種類である。

情報ＩＦ系８は、ホスト車両２の外部に存在する他道路ユーザ３と、運転システムＤＳとの間において運転処理に関連する報知情報の伝達を、媒介する。そのために情報ＩＦ系８には、外部報知ユニット８２が含まれている。

外部報知ユニット８２は、他道路ユーザ３としての歩行者等の人間、又は他道路ユーザ３としての他車両に搭乗する人間の、視覚をホスト車両２の外部環境において刺激することより、報知情報を提示してもよい。視覚情報提示タイプの外部報知ユニット８２は、例えばハザードランプ、方向指示ランプ、照明ライト、投影ライト、電子ステッカー、及び車外表示ユニット等のうち、少なくとも一種類である。ここで、外部報知ユニット８２としての電子ステッカーは、ホスト車両２が例えば、自動運転車又は自動運転中であることを表示する自動運転専用ステッカー等であってもよい。外部報知ユニット８２は、他道路ユーザ３としての歩行者等の人間、又は他道路ユーザ３としての他車両に搭乗する人間の、聴覚をホスト車両２の外部環境において刺激することより、報知情報を提示してもよい。聴覚情報提示タイプの外部報知ユニット８２は、例えば電子ホーン、スピーカ、及びブザー等のうち、少なくとも一種類である。

処理システム１は、例えばＬＡＮ（local area network）、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介してアクチュエータ系４、センサ系５、通信系６、地図ＤＢ７、及び情報ＩＦ系８に接続される。処理システム１は、少なくとも一つの専用コンピュータを含んで構成される。

処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御を統合する、統合ＥＣＵ（electronic control unit）であってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御において検出されたセンサデータを処理する、検出ＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御において認識を行う、認識ＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御におけるＤＤＴを判断して計画する、判断ＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御を監視する、監視ＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の運転制御を評価する、評価ＥＣＵであってもよい。

処理システム１を構成する専用コンピュータは、ホスト車両２の走行経路をナビゲートする、ナビゲーションＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ホスト車両２の自己位置を含んだ自己状態量を推定する、ロケータＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、アクチュエータ系４を制御する、アクチュエータＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、ＨＭＩ機器８０を制御する、ＨＣＵ（HMI control unit）であってもよい。処理システム１を構成する専用コンピュータは、データ記憶を制御する、記憶ＥＣＵであってもよい。処理システム１を構成する専用コンピュータは、例えば通信系６を介して通信可能な外部センタ又はモバイル端末等を構築する、少なくとも一つの外部コンピュータであってもよい。

処理システム１を構成する専用コンピュータは、メモリ１０とプロセッサ１２とを少なくとも一つずつ有している。メモリ１０は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。プロセッサ１２は、例えばＣＰＵ（central processing unit）、ＧＰＵ（graphics processing unit）、及びＲＩＳＣ（reduced instruction set computer）－ＣＰＵ等のうち、少なくとも一種類をコアとして含む。

メモリ１０は、運転システムＤＳにおける認識情報、判断情報、監視情報、及び制御情報のうち少なくとも一種類を選択してデータ蓄積する、蓄積装置であってもよい。メモリ１０は、運転システムＤＳにおける認識情報、判断情報、監視情報、及び制御情報のうち少なくとも一種類を一時的にデータ記憶する、例えばＲＡＭ（random access memory）等の揮発性記憶媒体であってもよい。メモリ１０は、運転システムＤＳにおいてＤＤＴを実行するための、データベースであってもよい。

メモリ１０は、着脱不能且つ交換不能に基板に実装されていてもよく、この構成としては、例えばフラッシュメモリを用いたｅＭＭＣ（embedded multi media card）等が挙げられる。メモリ１０は、着脱可能且つ交換可能に構成されていてもよく、この構成としては、例えばＳＤカード等が挙げられる。メモリ１０は、プロセッサ１２及び入出力ＩＦと共に一チップに集約されたＳｏＣ（system on a chip）により、処理システム１を構成する専用コンピュータを実現していてもよい。

プロセッサ１２は、ソフトウェアとしてメモリ１０に記憶された処理プログラムに含まれる複数の命令を、実行する。これにより、処理システム１を含む運転システムＤＳは、ホスト車両２の運転処理を遂行するための機能ブロックを、複数構築する。このように運転システムＤＳでは、処理システム１を主体としてホスト車両２の運転処理を遂行するためにメモリ１０に記憶の処理プログラムが複数の命令をプロセッサ１２に実行させることにより、複数の機能ブロックが構築される。こうして運転システムＤＳにおいて構築される複数の機能ブロックには、図３に機能アーキテクチャとして示されるように認識ブロック１００、判断ブロック１２０、及び制御ブロック１４０が含まれる。

認識ブロック１００は、センサ系５からセンサデータを取得する。認識ブロック１００は、通信系６から通信データを取得する。認識ブロック１００は、地図ＤＢ７から地図データを取得する。認識ブロック１００は、これらの取得データを個別に処理してからフュージョンすることにより、ホスト車両２の内外環境を認識する。認識情報の生成に当たって認識ブロック１００は、センサ系５、通信系６及び地図ＤＢ７からデータを取得し、取得データの意味を理解又は把握し、ホスト車両２の外部環境及びその中での自己の置かれた状況、並びにホスト車両２の内部環境を含む状況全般を、取得データのフュージョンによって認識する。内外環境の認識により認識ブロック１００は、判断ブロック１２０へ与える認識情報を生成する。

認識ブロック１００が生成する認識情報は、ホスト車両２の走行環境においてシーン毎に検知される状態を、記述する。認識ブロック１００は、ホスト車両２の外部環境における他道路ユーザ３、障害物、及び構造物を含む物体を、検知（sense）することにより、当該物体の認識情報を生成してもよい。物体の認識情報は、例えば離間距離、運動方向、相対速度、相対加速度、サイズ、追尾検知による推定状態等のうち、少なくとも一種類を表していてもよい。物体の認識情報は、例えばセマンティックセグメンテーション（semantic segmentation）等によりクラスタリングされた物体の状態に基づき認識される、当該物体の分類を表していてもよい。認識ブロック１００は、ホスト車両２の現在及び将来に走行する走路を検知することにより、当該走路の認識情報を生成してもよい。走路の認識情報は、例えば路面、車線、道路端、及びフリースペース等のうち、少なくとも一種類の静的構造を表していてもよい。

認識ブロック１００は、ホスト車両２の自己位置を含む自己状態量を推定的に認識するローカリゼーションにより、当該自己状態量の認識情報を生成してもよい。認識ブロック１００は、自己状態量の認識情報と同時に、ホスト車両２の走路に関する地図データの更新データを生成して、当該更新データを地図ＤＢ７へフィードバックしてもよい。認識ブロック１００は、ホスト車両２の走路に関連付けられた標示を検知することにより、当該標示の認識情報を生成してもよい。標示の認識情報は、例えば標識、区画線、及び信号機等のうち、少なくとも一種類の状態を表していてもよい。標示の認識情報はさらに、標示の状態から認識又は特定される交通ルールを、表していてもよい。認識ブロック１００は、ホスト車両２の走行するシーン毎の気象状況を検知することにより、当該気象状況の認識情報を生成してもよい。認識ブロック１００は、ホスト車両２の走行シーン毎の時刻を検知することにより、当該時刻の認識情報を生成してもよい。

判断ブロック１２０は、認識ブロック１００から認識情報を取得する。判断ブロック１２０は、取得した認識情報に基づくことにより、ホスト車両２に対する他道路ユーザ３の将来行動を時系列に予測する。予測される将来行動は、ホスト車両２との間において潜在的リスクを予見可能な、他道路ユーザ３のリスク行動を含んでいてもよい。予測される将来行動は、他道路ユーザ３の将来軌道であってもよい。ここで将来軌道は、例えば位置、速度、加速度、ヨーレート、及び運動方向等のうち、他道路ユーザ３に関する少なくとも一種類の運動物理量を時系列に規定するように、予測されるとよい。

判断ブロック１２０は、他道路ユーザ３の将来行動を予測する上での基礎処理として、ホスト車両２の置かれている走行環境の解釈を行ってもよい。このとき判断ブロック１２０は、動的物体である他道路ユーザ３の分類に基づき意図及び行動を解釈してもよいし、分類可能な運転状況を解釈してもよい。ここで他道路ユーザ３の意図及び行動解釈は、例えば車線変更確率等の解釈である。運転状況の解釈は、例えば交通ルール、及び渋滞状況等の解釈である。このような行動予測の基礎となる環境解釈は、認識ブロック１００により少なくとも一部が実行されることにより、認識情報としての解釈結果が判断ブロック１２０へと与えられてもよい。

判断ブロック１２０は、運転制御によってホスト車両２に将来走行させるルートを、計画する。即ち判断ブロック１２０は、ホスト車両２の戦略的機能としてルートを計画する、ＤＤＴ機能を実現する。判断ブロック１２０は、ホスト車両２の自己位置を推定した認識情報に基づくことにより、目的地までのルートと車線とのうち少なくとも一種類を計画してもよい。このとき判断ブロック１２０は、計画した車線に基づくことにより、車線変更要求と減速要求とのうち少なくとも一種類を計画してもよい。

判断ブロック１２０は、計画したルート及び車線に基づく共に、予測した他道路ユーザ３の将来行動に基づき、ホスト車両２の将来挙動を計画する。即ち判断ブロック１２０は、ホスト車両２の戦術的挙動を計画する、ＤＤＴ機能を実現する。判断ブロック１２０による挙動計画機能には、ホスト車両２の状態遷移に関する遷移条件を生成する機能が、含まれていてもよい。ホスト車両２の状態遷移に関する遷移条件は、トリガ条件（triggering condition）に対応していてもよい。そこで挙動計画機能には、生成した遷移条件に基づくことにより、ＤＤＴを実現するアプリケーションの状態遷移、さらには運転行動の状態遷移を決定する機能が、含まれていてもよい。

判断ブロック１２０は、計画したルートに沿ってホスト車両２に与える将来軌道を、予測した他道路ユーザ３の将来行動に基づき計画する。即ち判断ブロック１２０は、パスプランとしてホスト車両２に走行させる将来軌道を計画する、ＤＤＴ機能を実現する。判断ブロック１２０が計画する将来軌道は、ホスト車両２に関する運動物理量として、例えば位置、速度、加速度、ヨーレート、及び運動方向等のうち、少なくとも一種類を時系列に規定してもよい。規定される時系列な軌道計画は、ホスト車両２のナビゲートによる将来走行のシナリオを、構築することになる。そこで軌道計画には、複数のパスプランの中から最適なパスプランを選択又は切り替える機能が、含まれていてもよい。

判断ブロック１２０は、認識ブロック１００でのドライバに関する認識情報として、例えば意図推定情報、及び生体情報等のうち少なくとも一種類に基づき、ドライバの意図に応じた運転システムＤＳによる運転モードの遷移を判断してもよい。判断ブロック１２０は、認識ブロック１００でのドライバに関する認識情報として、例えば意図推定情報、及び生体情報等のうち少なくとも一種類に基づき、ドライバの障害有無を判断してもよい。判断ブロック１２０は、運転システムＤＳを監視することにより、各物理的構成要素１，４～８の障害有無を判断してもよい。判断ブロック１２０は、運転モードの遷移判断結果、ドライバの障害判断結果、運転システムＤＳの障害判断結果、将来ルートの計画結果、将来挙動の計画結果、及び将来軌道の計画結果等のうち少なくとも一種類に基づくことにより、ホスト車両２の運転に関する機能の制約を設定してもよい。

判断ブロック１２０は、ホスト車両２における自動運転レベルの調整を計画してもよい。自動運転レベルの調整には、自動運転と手動運転との間において運転モードが遷移することにより、運転システムＤＳとドライバとの間においてＤＤＴの移譲される引き継ぎ（takeover / handover）が、含まれていてもよい。自動運転と手動運転との間での引き継ぎは、自動運転を実行する運行設計領域（operational design domain：ＯＤＤ）の設定により、当該ＯＤＤに対する進入又は退出に伴うシナリオにおいて実現されてもよい。例えばＯＤＤからの退出シナリオ、即ち自動運転から手動運転への引き継ぎシナリオでは、不合理なリスクが存在すると判断される不合理な状況が、ユースケースとして挙げられる。このユースケースにおいて判断ブロック１２０は、フォールバック予備ユーザとなるドライバが手動運転によりホスト車両２を最小リスク状態（minimal risk condition：ＭＲＣ）へ遷移させるための、ＤＤＴフォールバックを計画してもよい。

判断ブロック１２０により計画される自動運転レベルの調整には、ホスト車両２の縮退走行が含まれてもよい。縮退走行のシナリオでは、手動運転への引き継ぎによっては不合理なリスクが存在すると判断される不合理な状況が、ユースケースとして挙げられる。このユースケースにおいて判断ブロック１２０は、事故の危害又はリスクを最小限にするために、自律走行及び自律停止によってホスト車両２をＭＲＣへと遷移させるための、ベストエフォートを計画してもよい。こうしたベストエフォートでは、自動運転レベルを引き下げる調整の他、自動運転レベルを維持した調整として、例えば安全状態としてのＭＲＣへ到達させる、ＤＤＴフォールバック又は最小リスク操作（minimum risk manoeuvre：ＭＲＭ）等の、緊急操作（emergency manoeuvre / emergency operation）が計画されてもよい。このとき、例えば各種感覚刺激、及び通信等のうち、情報ＩＦ系８又は通信系６を用いた少なくとも一種類により、ホスト車両２の内外に対してＭＲＣへの遷移状況の目立ち易さを高めるように、緊急操作に伴う報知が計画されてもよい。

判断ブロック１２０は、以上説明した計画のうち、少なくともルート計画、挙動計画、軌道計画、及び運転レベル計画に従って、ホスト車両２の運転制御をさらに計画する。運転制御の計画では、ホスト車両２のナビゲーション動作とドライバの支援動作とに関する制御指令が、制御アクションとして生成される。即ち判断ブロック１２０は、ホスト車両２の運動制御要求となる制御アクションを計画する、ＤＤＴ機能を実現する。判断ブロック１２０が生成する制御指令は、アクチュエータ系４を制御するための制御パラメータを、含んでいてもよい。このような制御計画は、後述の運転制御に先立って制御ブロック１４０により行われてもよい。

制御計画において判断ブロック１２０は、運転ポリシとその安全性に従って記述された安全モデルを用いることにより、当該運転ポリシと適合する制御アクションを計画してもよい。ここで安全モデルの従う運転ポリシは、意図された機能の安全性（safety of the intended functionality：ＳＯＴＩＦ）を保証する車両レベル安全戦略（vehicle level SOTIF strategy：ＶＬＳＳ）等を踏まえて、規定される。換言すれば安全モデルは、ＶＬＳＳの実装となる運転ポリシに従うことにより、且つＳＯＴＩＦをモデリングすることにより、記述される。

安全モデルは、他道路ユーザ３の合理的に予見可能な行動についての仮定に基づく運転行動の安全関連側面を表現した、安全関連モデル（safety-related models）そのものに定義されてもよいし、当該安全関連モデルのうち一部を構成するモデルに定義されてもよい。このような安全モデルは、例えば車両レベル安全を定式化した数理モデル、及び当該数理モデルに従った処理を実行するコンピュータプログラム等のうち、少なくとも一種類の形態で構築されるとよい。そこで判断ブロック１２０は、後段の制御ブロック１４０による運転制御結果を安全モデルに逆伝播させる機械学習アルゴリズムにより、安全モデルをトレーニングしてもよい。トレーニングされる安全モデルとしては、例えばＤＮＮ（deep neural network）といったニュラーラルネットワークによるディープラーニング、及び強化学習等のうち、少なくとも一種類の学習モデルが用いられてもよい。

制御ブロック１４０は、判断ブロック１２０から制御指令を取得する。制御ブロック１４０は、計画された制御指令に従ってホスト車両２の運転を制御する。即ち制御ブロック１４０は、ホスト車両２に制御アクションを与える、ＤＤＴ機能を実現する。このとき制御ブロック１４０は、例えばホスト車両２に関して車両運動等の認識情報を、認識ブロック１００から又は判断ブロック１２０を経由して取得することにより、車両制御に利用してもよい。制御ブロック１４０はさらに、判断ブロック１２０によって報知の計画が行われた場合には、情報ＩＦ系８及び通信系６のうち少なくとも一方を制御することにより、当該報知の出力を行ってもよい。

第一実施形態では、図４に示されるフローチャートに従ってホスト車両２の運転処理を遂行する処理方法のフロー（以下、処理フローと称する）が、複数ブロック１００，１２０，１４０の共同により繰り返し実行される。ここで第一実施形態の処理フローは、例えば運転システムＤＳによりホスト車両２がレベル３の自動運転状態に制御されている状況等において、開始される。尚、以下の説明において処理フローの各「Ｓ」は、処理プログラムに含まれた複数命令により実行される複数ステップを、それぞれ意味する。

Ｓ１００において判断ブロック１２０は、ノミナル状態のホスト車両２を運転システムＤＳによりＭＲＣへ遷移させる緊急操作を、要否判断する。このとき判断ブロック１２０は、緊急操作のトリガ条件として緊急条件が成立したか否かを、監視する。ここでノミナル状態とは、ホスト車両２が例えば故障、機能不十分性、又は潜在的に危険な挙動等から解放されて運転システムＤＳによりノミナル操作されている状態に、定義されてもよい。換言すれば緊急条件は、例えば障害、機能不十分性、又は潜在的に危険な挙動等により、ホスト車両２において緊急操作の実行が必要となる条件に、定義されてもよい。

具体的にはＳ１００によって判断される緊急条件は、運転システムＤＳにおける少なくとも一種類の物理的要素又は機能ブロックに障害が発生し、且つドライバへのＤＤＴの引き継ぎに障害が発生した場合に、成立する。ここで運転システムＤＳにおける物理的要素の障害は、例えばセンサ系５に含まれる外部環境センサ５０の検出範囲又は視野の減少等といった、不調であってもよい。運転システムＤＳにおける機能ブロックの障害は、例えば認識ブロック１００による認識範囲の減少等といった、不調であってもよい。引き継ぎにおける障害は、物理的要素又は機能ブロックの障害発生に応答してＨＭＩ機器８０によりドライバへと報知される引き継ぎ要求に対して、例えばドライバの引き継ぎ意図がＨＭＩ機器８０若しくは内部環境センサ５２により特定時間フレーム内に検出されない、不調であってもよい。引き継ぎにおける障害は、物理的要素又は機能ブロックの障害発生に応答してＨＭＩ機器８０若しくは内部環境センサ５２により、例えば姿勢、視線、及び意識等の少なくとも一種類に関する引き継ぎに不適合なドライバの生体状態が検出される、不調であってもよい。こうした引き継ぎに不適合な生体状態としては、例えばホスト車両２の進行方向からドライバの視線が外れる脇見等が、挙げられる。

Ｓ１００において緊急条件が成立すると、処理フローがＳ１０１へ移行する。Ｓ１０１において判断ブロック１２０は、ＭＲＣへ遷移するように緊急操作を与える制御アクションを、計画する。このとき緊急操作を与える制御アクションは、例えばレーン内での減速、レーン内での緊急停止、レーン内での自律走行後における自律停止、及びレーン外への脱出等のうち、適切な応答（proper response）又は障害反応（fault reaction）として少なくとも一種類である。このようなＳ１０１においては、判断ブロック１２０が計画した緊急操作の制御アクションを、制御ブロック１４０がホスト車両２に対して与えることとなる。

Ｓ１０１において判断ブロック１２０は、計画した制御アクションに合わせた緊急操作の報知を、さらに計画するとよい。このときの報知計画は、情報ＩＦ系８のうちＨＭＩ機器８０からホスト車両２内のドライバへ緊急操作を報知するための、報知データの生成を含んでいてもよい。報知計画は、情報ＩＦ系８のうち外部報知ユニット８２からホスト車両２外の人間へ緊急操作を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により外部センタへ緊急操作を報知するための、報知データの生成を含んでいてもよい。このようなＳ１０１においては、判断ブロック１２０が計画した緊急操作の報知データを、制御ブロック１４０がホスト車両２において出力させることとなる。

Ｓ１０１に続くＳ１０２において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の当該緊急操作からの運転復帰を、要否判断する。このとき判断ブロック１２０は、緊急条件の少なくとも一部が解消される復帰条件が成立したか否かを、監視する。具体的にＳ１０２によって判断される運転復帰は、第一実施形態ではドライバへのＤＤＴの引き継ぎにおける障害の解消を、少なくともトリガ条件とする。即ちＳ１０２によって判断される復帰条件には、運転システムＤＳ及び引き継ぎの各障害が共に解消した場合に成立する完全復帰条件と、運転システムＤＳに障害が継続し且つドライバへの引き継ぎの障害が解消した場合に成立するドライバ優先復帰条件とが、含まれる。

ここで運転システムＤＳにおける障害の解消は、運転システムＤＳの能力又は機能が全て回復することにより、判断されてもよい。引き継ぎにおける障害の解消は、例えば姿勢、視線、又は意識等の、引き継ぎに適合するドライバの生体状態がＨＭＩ機器８０又は内部環境センサ５２によって検出されることにより、判断されてもよい。引き継ぎにおける障害の解消は、ＨＭＩ機器８０によりドライバへ報知される引き継ぎ要求に対して、例えばドライバの引き継ぎ意図がＨＭＩ機器８０又は内部環境センサ５２によって特定時間フレーム内に検出されることにより、判断されてもよい。

尚、Ｓ１０１による制御アクションに従ってホスト車両２が停止した後には、ホスト車両２の起動スイッチがドライバ又は運転システムＤＳ（例えば判断ブロック１２０等）によってオフされる場合が、想定される。そこで図示は省略されるが、Ｓ１０２の開始タイミング毎に起動スイッチの状態が監視されることにより、起動スイッチのオフに応答して処理フローの今回実行が終了するようになっている。

Ｓ１０２において、運転システムＤＳ及び引き継ぎの各障害が共に解消する完全復帰条件が成立すると、処理フローはＳ１０３へ移行する。Ｓ１０３において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の運転復帰として、運転システムＤＳをノミナル状態へと回復させる完全復帰の判断をすることにより、当該完全復帰の制御アクションを計画する。即ち第一実施形態ではノミナル状態が、運転システムＤＳを緊急操作の状態から遷移させる回復状態となる。これによりＳ１０３においては、判断ブロック１２０が計画した制御アクションによる運転システムＤＳのノミナル状態への運転復帰を、制御ブロック１４０がホスト車両２に与えることとなる。

Ｓ１０３において判断ブロック１２０は、計画した制御アクションによる運転復帰に合わせて、運転システムＤＳによりノミナル状態での自動運転が再開される完全復帰の報知を、さらに計画する。このときの報知計画は、情報ＩＦ系８のうちＨＭＩ機器８０からホスト車両２内のドライバへ完全復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、情報ＩＦ系８のうち外部報知ユニット８２からホスト車両２外の人間へ完全復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により外部センタへ完全復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により他道路ユーザ３のモバイル端末へ完全復帰を報知するための、報知データの生成を含んでいてもよい。このようなＳ１０３においては、判断ブロック１２０が計画した完全復帰の報知データを、制御ブロック１４０がホスト車両２において出力させることとなる。

ここでホスト車両２外への完全復帰の報知は、視覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき視覚刺激による完全復帰の報知は、例えばハザードランプ等といった外部報知ユニット８２の点滅により、実現されてもよい。ホスト車両２外への完全復帰の報知は、聴覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき聴覚刺激による完全復帰の報知は、例えば電子ホーン等といった外部報知ユニット８２の作動により、実現されてもよい。これら視覚刺激及び聴覚刺激のいずれの場合にも完全復帰の報知は、当該報知を必要とする他道路ユーザ３への指向性をもって、ホスト車両２外の例えば後方等に向けて行われてもよい。

一方でＳ１０２において、運転システムＤＳに障害が継続し且つドライバへの引き継ぎの障害が解消するドライバ優先復帰条件が成立すると、処理フローはＳ１０４へ移行する。Ｓ１０４において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の運転復帰として、ドライバへのＤＤＴの引き継ぎを優先させるドライバ優先復帰の判断をすることにより、当該ドライバ優先復帰の制御アクションを計画する。このときドライバ優先復帰の制御アクションは、ＨＭＩ機器８０により引き継ぎ要求をドライバへと報知して、少なくともドライバの引き継ぎ意図をＨＭＩ機器８０により検出するまで、アクチュエータ系４により緊急操作を維持することであってもよい。ドライバ優先復帰の制御アクションは、ドライバの引き継ぎ意図が既検出の場合又は検出された後に、ＤＤＴの引き継がれたドライバによる手動運転状態を維持させることであってよい。このようなＳ１０４においては、判断ブロック１２０が計画した制御アクションによりＤＤＴをドライバへと引き継ぐ運転復帰を、制御ブロック１４０がホスト車両２に与えることとなる。

Ｓ１０４において判断ブロック１２０は、計画した制御アクションによる運転復帰に合わせて、ＤＤＴの引き継がれたドライバにより手動運転が開始されるドライバ優先復帰の報知を、さらに計画する。このときの報知計画は、情報ＩＦ系８のうち外部報知ユニット８２からホスト車両２外の人間へドライバ優先復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により外部センタへドライバ優先復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により他道路ユーザ３のモバイル端末へドライバ優先復帰を報知するための、報知データの生成を含んでいてもよい。このようなＳ１０４においては、判断ブロック１２０が計画したドライバ優先復帰の報知データを、制御ブロック１４０がホスト車両２において出力させることとなる。

ここでホスト車両２外へのドライバ優先復帰の報知は、視覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき視覚刺激によるドライバ優先復帰の報知は、例えばハザードランプ等といった外部報知ユニット８２の点滅パターンが完全復帰の場合とは相違パターン、又は共通パターンに設定されることにより、実現されてもよい。ホスト車両２外へのドライバ優先復帰の報知は、聴覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき聴覚刺激によるドライバ優先復帰の報知は、例えば電子ホーン等といった外部報知ユニット８２の作動パターンが完全復帰の場合とは相違パターン、又は共通パターンに設定されることにより、実現されてもよい。これら視覚刺激及び聴覚刺激のいずれの場合にもドライバ優先復帰の報知は、当該報知を必要とする他道路ユーザ３への指向性をもって、ホスト車両２外の例えば後方等に向けて行われてもよい。

以上において、Ｓ１０３の実行が完了した場合には、処理フローの今回実行が終了する。これに対して、Ｓ１０４の実行が完了した場合には完全復帰まで運転復帰の制御が継続するように、処理フローがＳ１０２へリターンされる。但し、Ｓ１０４からＳ１０２へのリターン後に繰り返される場合のＳ１０４では、当該繰り返しの最先となるＳ１０４の実行から経過した時間が設定時間超過、又は設定時間以上となった場合に、報知の計画及び実行が省かれてもよい。また、Ｓ１０４からＳ１０２へのリターン後に完全復帰条件が成立した場合のＳ１０３では、報知の計画及び実行が省かれてもよい。

ここまで説明した第一実施形態では、運転システムＤＳにより緊急操作されたホスト車両２の当該緊急操作からの運転復帰が、判断される。そこで第一実施形態によると、ホスト車両２外には、ホスト車両２の運転復帰が報知されることになる。これによれば、報知されるホスト車両２の外部環境に存在する他道路ユーザ３は、緊急操作されたホスト車両２の運転復帰に対して、当該報知に応じた対応を採ることができる。故に、他道路ユーザ３の対応力向上に貢献することが可能となる。

（第二実施形態）
第二実施形態は、第一実施形態の変形例である。第二実施形態による処理フローは、運転システムＤＳによりホスト車両２がレベル３の自動運転状態に制御されている状況等に、開始される。

図５に示されるように第二実施形態の処理フローでは、Ｓ１０２に代わるＳ２０２が、Ｓ１０１に続いて実行される。具体的にはＳ２０２によって判断される運転復帰は、ドライバへのＤＤＴの引き継ぎにおける障害の解消と、運転システムＤＳにおける障害の解消とのうち、少なくとも一方をトリガ条件とする。即ちＳ２０２によって判断される復帰条件には、第一実施形態に準ずる完全復帰条件及びドライバ優先復帰条件に加えて、ドライバへの引き継ぎに障害が継続し且つ運転システムＤＳの障害が解消した場合に成立するシステム優先復帰条件が、さらに含まれる。

そこでＳ２０２において、ドライバへの引き継ぎに障害が継続し且つ運転システムＤＳの障害が解消する、システム優先復帰条件が成立した場合に第二実施形態では、処理フローがＳ２０５へ移行する。尚、Ｓ２０２において完全復帰条件とドライバ優先復帰条件とのうち一方が成立した場合には、処理フローがＳ１０３，Ｓ１０４のうち当該一方に対応するステップへ移行するため、以下において説明は省略されている。

Ｓ２０５において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の当該緊急操作からの運転復帰として、ドライバへの引き継ぎなしに運転システムＤＳの回復を優先させるシステム優先復帰の判断をすることにより、当該システム優先復帰の制御アクションを計画する。このような第二実施形態では、Ｓ１０３による完全復帰先のノミナル状態に加えて、ドライバへの引き継ぎは保留若しくは停止するようにノミナル操作が制限又は縮退された状態（以下、準ノミナル状態と称する）が、運転システムＤＳを緊急操作の状態から遷移させる回復状態となる。これによりＳ２０５においては、判断ブロック１２０が計画した制御アクションによる運転システムＤＳの準ノミナル状態への運転復帰を、制御ブロック１４０がホスト車両２に与えることとなる。

Ｓ２０５において判断ブロック１２０は、計画した制御アクションによる運転復帰に合わせて、運転システムＤＳにより準ノミナル状態での自動運転が開始されるシステム優先復帰の報知を、さらに計画する。このときの報知計画は、情報ＩＦ系８のうちＨＭＩ機器８０からホスト車両２内のドライバへシステム優先復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、情報ＩＦ系８のうち外部報知ユニット８２からホスト車両２外の人間へシステム優先復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により外部センタへシステム優先復帰を報知するための、報知データの生成を含んでいてもよい。報知計画は、通信系６からホスト車両２外へ送信される、例えばブロードキャスト等により他道路ユーザ３のモバイル端末へシステム優先復帰を報知するための、報知データの生成を含んでいてもよい。このようなＳ２０５においては、判断ブロック１２０が計画したシステム優先復帰の報知データを、制御ブロック１４０がホスト車両２において出力させることとなる。

ここでホスト車両２外へのシステム優先復帰の報知は、視覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき視覚刺激によるシステム優先復帰の報知は、例えばハザードランプ等といった外部報知ユニット８２の点滅パターンが完全復帰及びドライバ優先復帰の各場合とは相違パターン、又は共通パターンに設定されることにより、実現されてもよい。ホスト車両２外へのドライバ優先復帰の報知は、聴覚刺激可能に出力される報知データを判断ブロック１２０が生成することに応答して、実行されてもよい。このとき聴覚刺激によるシステム優先復帰の報知は、例えば電子ホーン等といった外部報知ユニット８２の作動パターンが完全復帰及びドライバ優先復帰の各場合とは相違パターン、又は共通パターンに設定されることにより、実現されてもよい。これら視覚刺激及び聴覚刺激のいずれの場合にもシステム優先復帰の報知は、当該報知を必要とする他道路ユーザ３への指向性をもって、ホスト車両２外の例えば後方等に向けて行われてもよい。

以上において、Ｓ２０５の実行が完了した場合には完全復帰まで運転復帰の制御が継続するように、処理フローがＳ１０２へリターンされる。但し、Ｓ２０５からＳ１０２へのリターン後に繰り返される場合のＳ２０５では、当該繰り返しの最先となるＳ２０５の実行から経過した時間が設定時間超過、又は設定時間以上となった場合に、報知の計画及び実行が省かれてもよい。また、Ｓ２０５からＳ１０２へのリターン後に完全復帰条件が成立した場合のＳ２０５では、報知の計画及び実行が省かれてもよい。このような第二実施形態においても、第一実施形態に準ずる原理により、他道路ユーザ３の対応力向上に貢献することが可能となる。

（第三実施形態）
第三実施形態は、第一実施形態の変形例である。第三実施形態による処理フローは、例えば運転システムＤＳによりホスト車両２がレベル３の自動運転状態に制御されている状況等に、開始される。

図６に示されるように第三実施形態の処理フローでは、Ｓ１０２に代わるＳ３０２が、Ｓ１０１に続いて実行される。具体的にＳ３０２によって判断される運転復帰は、ドライバへのＤＤＴの引き継ぎにおける障害の解消のみを、トリガ条件とする。即ち第一実施形態において説明のドライバ優先復帰条件が、第三実施形態ではＳ３０２による唯一の復帰条件として、含まれることになる。

そこで第三実施形態の処理フローでは、Ｓ１０３の実行が省かれる一方、Ｓ３０２による成立条件に応じたＳ１０４の処理が、ドライバ優先復帰を唯一の運転復帰として実行される。このような第二実施形態においても、第一実施形態に準ずる原理により、他道路ユーザ３の対応力向上に貢献することが可能となる。

（第四実施形態）
第四実施形態は、第二実施形態の変形例である。第四実施形態による処理フローは、例えば運転システムＤＳによりホスト車両２がレベル３の自動運転状態に制御されている状況等に、開始される。

図７に示されるように第四実施形態の処理フローでは、Ｓ２０２に代わるＳ４０２が、Ｓ１０１に続いて実行される。具体的にＳ４０２によって判断される運転復帰は、運転システムＤＳにおける障害の解消を、少なくともトリガ条件とする。即ちＳ４０２による復帰条件には、第一実施形態において説明の完全復帰条件と、第二実施形態において説明のシステム優先復帰条件とが、含まれることになる。

そこで第四実施形態の処理フローでは、Ｓ１０４の実行が省かれる一方、Ｓ４０２による成立条件に応じたＳ１０３又はＳ２０５の処理が実行される。このような第四実施形態においても、第一実施形態に準ずる原理により、他道路ユーザ３の対応力向上に貢献することが可能となる。

（第五実施形態）
第五実施形態は、第四実施形態の変形例である。第五実施形態による処理フローは、例えば運転システムＤＳによりホスト車両２がレベル４又は５の自動運転状態に制御されている状況等に、開始される。

図８に示されるように、第五実施形態による処理フローでは、Ｓ１００，Ｓ４０２にそれぞれ代わるＳ５００，Ｓ５０２が、実行される。具体的にＳ５００により判断される緊急操作は、運転システムＤＳにおける少なくとも一種類の物理的要素又は機能ブロックに障害が発生したことのみを、トリガ条件とする。即ちＳ５００によって判断される緊急条件には、第一実施形態において説明した物理的要素又は機能ブロックの障害発生が、緊急操作を実行する唯一の成立条件として含まれることになる。

Ｓ５００に応じてＳ１００実行後のＳ５０２によって判断される運転復帰は、運転システムＤＳにおける障害の解消のみを、トリガ条件とする。即ち、運転システムＤＳにおける障害が解消した場合に成立する完全システム復帰条件が、Ｓ５０２による唯一の復帰条件として含まれることになる。

そこで第五実施形態の処理フローでは、Ｓ２０５の実行が省かれる一方、Ｓ５０２による成立条件に応じてＳ１０３の処理が、完全復帰に準ずる完全システム復帰を唯一の運転復帰として実行される。但し、このＳ１０３での報知計画は、情報ＩＦ系８のうちＨＭＩ機器８０から、手動運転機能があるホスト車両２内のドライバ、又は手動機能のないホスト車両２内の乗員へ完全システム復帰を報知するための、報知データの生成を含んでいてもよい。このような第五実施形態においても、第一実施形態に準ずる原理により、他道路ユーザ３の対応力向上に貢献することが可能となる。

（第六実施形態）
第六実施形態は、第一実施形態の変形例である。第六実施形態による処理フローは、例えば運転システムＤＳによりホスト車両２がレベル３の自動運転状態に制御されている状況等において、開始される。

図９に示されるように、第六実施形態による処理フローでは、Ｓ１０２において、運転システムＤＳの障害が解消し且つドライバへの引き継ぎの障害が解消した完全復帰条件が成立すると、処理フローは、Ｓ６１０３へ移行する。

Ｓ６１０３において判断ブロック１２０は、運転システムＤＳ及び引き継ぎの各障害が共に解消した場合にあっても、ホスト車両２の外的環境要因として、運転システムＤＳのノミナル状態への遷移の規制を必要とする要因が、発生しているか否かを判定する。具体的にＳ６１０３によって判定される外的環境要因は、ホスト車両２の周囲外界に発生している、例えば交通事故、自然災害、道路工事、故障車両の存在、緊急車両の優先通過、警察署若しくは消防署のシステム要請、走行の規制、又は落下物の残留等といった、同車両２の走行を阻害するインシデントであってもよい。ここで外的環境要因は、図１０に示すホスト車両２外のうち、処理システム１の専用コンピュータを兼ねる外部センタ９ａ、又は処理システム１とは別の外部センタ９ａからの、通信データに基づき認識ブロック１００により認識されて、判断ブロック１２０により判断されるとよい。

Ｓ６１０３において否定判定が下される場合、即ち外的環境要因による運転システムＤＳのノミナル状態への遷移規制が不要となる場合には、完全復帰の判断確定により処理フローがＳ１０３へ移行する。これにより、Ｓ１０３において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の運転復帰として、完全復帰の制御アクション及び報知を第一実施形態と同様に計画する。

一方、Ｓ６１０３において肯定判定が下される場合、即ちホスト車両２の外的環境要因により運転システムＤＳのノミナル状態への遷移が規制される場合には、完全復帰からドライバ優先復帰への判断変更により処理フローがＳ１０４へ移行する。これにより、Ｓ１０４において判断ブロック１２０は、運転システムＤＳにより緊急操作されたホスト車両２の運転復帰として、ドライバ優先復帰の制御アクション及び報知を第一実施形態と同様に計画する。

但し、第六実施形態のＳ１０４では、図１０に示すようにホスト車両２と通信する外部センタ９ａから同車両２の周囲外界におけるインフラユニット９ｂへと与えられる制御命令に対して、協調するためのドライバ優先復帰を報知する報知データが、生成される。これは、外的環境要因の発生に伴って外部センタ９ａがインフラユニット９ｂへ与える制御命令と、報知データによる報知対象となるドライバ優先復帰での報知自体及び／又は制御アクションとが、相互に連動して協調することを意味する。

ここで、信号機９ｂｓである場合のインフラユニット９ｂは、外部センタ９ａからの制御命令に従って、外的環境要因に応じたホスト車両２のドライバ優先復帰での報知及び／又は制御アクションと協調するように、例えば交通誘導可能な状態等に点灯状態を制御されてもよい。デジタルサイネージ９ｂｄである場合のインフラユニット９ｂは、外部センタ９ａからの制御命令に従って、外的環境要因に応じたホスト車両２のドライバ優先復帰での報知及び／又は制御アクションと協調するように、例えば推奨行動等の表示内容を制御されてもよい。インフラカメラ９ｂｃである場合のインフラユニット９ｂは、外部センタ９ａからの制御命令に従って、外的環境要因に応じたホスト車両２のドライバ優先復帰での報知及び／又は制御アクションと協調するように、例えばズーム設定等の撮像状態を制御されてもよい。

第六実施形態のＳ１０４では、ドライバ優先復帰を報知するための報知データとして、ホスト車両２と通信する外部センタ９ａから同車両２の周囲外界における他道路ユーザ３のモバイル端末へ与えられる制御要要求に対して、協調するためのドライバ優先復帰を報知する報知データが、生成されてもよい。この場合にモバイル端末では、外部センタ９ａからの制御要求に従って、外的環境要因に応じたホスト車両２のドライバ優先復帰での報知及び／又は制御アクションと協調するように、例えば推奨行動等の表示内容が制御されてもよい。

第六実施形態のＳ１０４では、情報ＩＦ系８のうちＨＭＩ機器８０からホスト車両２内のドライバへ、外的環境要因により完全復帰が規制されてのドライバ優先復帰を報知するための報知データが、生成されてもよい。このとき報知データは、視覚刺激可能に出力されてもよいし、聴覚刺激可能に出力されてもよい。

尚、以上説明した第六実施形態は、図１１に変形例を示すように、第二実施形態にも適用されてよい。

（他の実施形態）
以上、複数の実施形態について説明したが、本開示は、それらの実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。

変形例において処理システム１を構成する専用コンピュータは、デジタル回路及びアナログ回路のうち、少なくとも一方をプロセッサとして有していてもよい。ここでデジタル回路とは、例えばＡＳＩＣ（application specific integrated circuit）、ＦＰＧＡ（field programmable gate array）、ＳＯＣ（system on a chip）、ＰＧＡ（programmable gate array）、及びＣＰＬＤ（complex programmable logic device）等のうち、少なくとも一種類である。またこうしたデジタル回路は、プログラムを記憶したメモリを、有していてもよい。

ホスト車両２における乗員のうちオペレータとなるドライバは変形例では、外部センタにおいてホスト車両２を遠隔操作する、リモートオペレータ又はリモートドライバにより代替されてもよい。運転システムＤＳ及び処理システム１の適用されるホスト移動体は、第五実施形態に関する変形例では、自律走行又はリモート走行によって荷物搬送若しくは情報収集等の可能な自律走行ロボットであってもよい。以上の他に各実施形態及び変形例による処理システム１は、ホスト移動体に搭載可能に構成されてプロセッサ１２及びメモリ１０を少なくとも一つずつ有する処理装置として、処理回路（例えば処理ＥＣＵ等）又は半導体装置（例えば半導体チップ等）の形態で実施されてもよい。

（用語の説明）
本開示に関連する用語を、以下に説明する。この説明は、本開示の実施形態に含まれる。

道路ユーザ（road user）は、歩道及びその他の隣接するスペースを含む道路を利用する人間であってもよい。道路ユーザは、ある場所から別の場所へ移動する目的で、アクティブな道路上、又は隣接している道路のユーザであってもよい。

他道路ユーザ（other road user）は、自動運転自車両の役割を果たさない脆弱な道路ユーザ及び非脆弱な道路ユーザであってもよい。

動的運転タスク（dynamic driving task：ＤＤＴ）は、交通において車両を操作するためのリアルタイムの操作機能及び戦術機能であってもよい。

自車両の挙動は、車両運動を交通状況で解釈したものであってもよい。ここで車両運動は、物理量（例えば速度、及び加速度等）の側面で捉えた車両状態とそのダイナミクスであってもよい。

シナリオは、アクション及びイベントの影響を受けた特定の状況での目標及び値を含む、一連のシーン内のいくつかのシーン間の時間的関係の描写であってもよい。シナリオは、特定の運転タスクを実行するプロセスにおける、主体となる車両、その全ての外部環境、及びそれらのインタラクションを統合する連続した時系列の活動の描写であってもよい。

状況は、システムの挙動に影響を与え得る要因であって、交通状況、天候、自車両の挙動を含んでいてもよい。

トリガ条件（triggering condition）は、後続のシステムの反応であって、危険な挙動、合理的に予見可能な間接的な誤用を防止、検出、及び軽減できないことに寄与する反応のきっかけとして機能するシナリオの特定条件であってもよい。

運行設計領域（operational design domain：ＯＤＤ）は、与えられた（自動）運転システムが機能するように設計された特定の条件であってもよい。運行設計領域は、与えられた（自動）運転システム又は特徴が機能するように特別に設計された動作条件であって、環境、地理、及び時刻の制限、及び／又は特定の交通又は道路の特徴の必要な存否が含まれるが、これらに限定されない動作条件であってもよい。

自動運転システム（automated driving system）は、特定のＯＤＤに限定されているか否かに関係なく、持続的に全体のＤＤＴを実行可能な一纏めのハードウェア及びソフトウェアであってもよい。

意図された機能の安全性（safety of the intended functionality：ＳＯＴＩＦ）は、意図された機能又はその実装の機能不十分性に起因する不当なリスクの不在であってもよい。

運転ポリシ（driving policy）は、車両レベルにおける制御行動を定義する戦略及び規則であってもよい。

車両レベル安全戦略（vehicle level SOTIF strategy：ＶＬＳＳ）は、ＳＯＴＩＦ関連の設計、検証、及び検証アクティビティを補助するために使用される開発中の機能の要件のセットであってもよい。

不合理なリスクは、妥当な社会的道徳的概念に従って、特定の状況で許容できないと判断されたリスクであってもよい。

安全関連モデル（safety-related models）は、他道路ユーザの合理的に予見可能な挙動についての想定に基づく、運転行動の安全関連の様相の表現であってもよい。安全関連モデルは、オンボード若しくはオフボードの安全確認装置又は安全解析装置、数理モデル、より概念的なルールのセット、シナリオベースの挙動のセット、あるいはこれらの組み合わせであってもよい。

適切な応答（proper response）は、他道路ユーザが合理的に予見可能な挙動についての想定に従って行動しているときに危険な状況を解決するアクションであってもよい。

安全状態は、合理的に安全な動作モードであってもよい。

最小リスク状態（minimal risk condition：ＭＲＣ）は、与えられたトリップを完了できない場合のリスクを軽減するための車両の状態であってもよい。最小リスク状態は、与えられたトリップを完了できない場合に、衝突のリスクを軽減するために、最小リスク操作を実行した後の車両をユーザ又は（自動）運転システムがもたらす状態であってもよい。

最小リスク操作（minimal risk manoeuvre：ＭＲＭ）は、ノミナル状態と最小リスク状態との間において遷移する（自動）運転システムの機能であってもよい。

ＤＤＴフォールバックは、故障の発生後若しくは機能不十分性の検出後、又は潜在的に危険な挙動の検出の際に、ＤＤＴ又はＭＲＣへの遷移を実行するための、ドライバ又は（自動）運転システムによる応答であってもよい。

緊急操作（emergency manoeuvre）は、車両が衝突の危険が迫っている事象の場合に、衝突を回避又は軽減する目的で実行される操作であってもよい。

引き継ぎ（takeover）は、（自動）運転システムとドライバとの間の運転タスクの移譲であってもよい。

ドライバは、特定車両のＤＤＴ及び／又はＤＤＴフォールバックの一部若しくは全部をリアルタイムで実行するユーザであってもよい。リモートドライバは、車載のブレーキ、アクセル、ステアリング、及びトランスミッションのギア選択入力装置を手動で操作できる位置に座っていないが、車両を操作できるドライバであってもよい。

オペレータは、自動車を操作するように適切な訓練を受け且つ権限を与えられた指定者であってもよい。リモートオペレータは、車載のブレーキ、アクセル、ステアリング、及びトランスミッションのギア選択入力装置を手動で操作できる位置に座っていないが、直視の有無にかかわらず車両を操作できるオペレータであってもよい。

（付言）
本明細書には、以下に列挙する複数の技術的思想と、それらの複数の組み合わせが開示されている。

（技術的思想１）
運転システム（ＤＳ）においてホスト移動体（２）の運転に関する処理を遂行するために、プロセッサ（１２）により実行される処理方法であって、
前記運転システムにより緊急操作された前記ホスト移動体の当該緊急操作からの運転復帰を、判断することと、
前記ホスト移動体外に前記運転復帰を、報知することとを、含む処理方法。

（技術的思想２）
前記運転復帰の判断は、
前記ホスト移動体のオペレータへ引き継ぐことによる前記運転復帰を、判断することを、含む技術的思想１に記載の処理方法。

（技術的思想３）
前記運転復帰の判断は、
前記運転システムに障害が継続し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合に、当該引き継ぎによる前記運転復帰の判断をすることを、含む技術的思想２に記載の処理方法。

（技術的思想４）
前記運転復帰の判断は、
前記運転システムを前記緊急操作からの回復状態へ遷移させることによる前記運転復帰を、判断することを、含む技術的思想１～３のいずれか一項に記載の処理方法。

（技術的思想５）
前記運転復帰の判断は、
前記運転システムの障害が解消し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合に、前記運転システムの前記回復状態への遷移による前記運転復帰の判断をすることを、含む技術的思想４に記載の処理方法。

（技術的思想６）
前記運転復帰の判断は、
前記運転システムの障害が解消し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合にあっても、前記ホスト移動体の外的環境要因により前記運転システムの前記回復状態への遷移が規制される場合に、当該引き継ぎによる前記運転復帰の判断をすることを、含む技術的思想５に記載の処理方法。

（技術的思想７）
前記運転復帰の判断は、
前記ホスト移動体におけるオペレータへの引き継ぎに障害が継続し且つ前記運転システムの障害が解消した場合に、前記運転システムの制限又は縮退された前記回復状態への遷移による前記運転復帰の判断をすることを、含む技術的思想４～６のいずれか一項に記載の処理方法。

（技術的思想８）
前記運転復帰の報知は、
前記ホスト移動体外へ送信されることにより前記運転復帰を報知する、報知データを生成することを、含む技術的思想１～７のいずれか一項に記載の処理方法。

（技術的思想９）
前記運転復帰の報知は、
前記ホスト移動体と通信する外部センタ（９ａ）から前記ホスト移動体の周囲におけるインフラユニット（９ｂ）へ与えられる制御命令に対して、協調するための前記運転復帰を報知する報知データを、生成することを、含む技術的思想１～８のいずれか一項に記載の処理方法。

（技術的思想１０）
前記運転復帰の報知は、
前記ホスト移動体外へ視覚刺激可能に出力されることにより前記運転復帰を報知する、報知データを生成することを、含む技術的思想１～９のいずれか一項に記載の処理方法。

（技術的思想１１）
前記運転復帰の報知は、
前記ホスト移動体外へ聴覚刺激可能に出力されることにより前記運転復帰を報知する、報知データを生成することを、含む技術的思想１～１０のいずれか一項に記載の処理方法。

尚、上述した技術的思想１～１１は、システム及びプログラムの各形態で実現されてもよい。

１：処理システム、２：ホスト車両、９ａ：外部センタ、９ｂ：インフラユニット、１０：メモリ、１２：プロセッサ、ＤＳ：運転システム

Claims (13)

1. 運転システム（ＤＳ）においてホスト移動体（２）の運転に関する処理を遂行するために、プロセッサ（１２）により実行される処理方法であって、
   前記運転システムにより緊急操作された前記ホスト移動体の当該緊急操作からの運転復帰を、判断することと、
   前記ホスト移動体外に前記運転復帰を、報知することとを、含む処理方法。
2. 前記運転復帰の判断は、
   前記ホスト移動体のオペレータへ引き継ぐことによる前記運転復帰を、判断することを、含む請求項１に記載の処理方法。
3. 前記運転復帰の判断は、
   前記運転システムに障害が継続し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合に、当該引き継ぎによる前記運転復帰の判断をすることを、含む請求項２に記載の処理方法。
4. 前記運転復帰の判断は、
   前記運転システムを前記緊急操作からの回復状態へ遷移させることによる前記運転復帰を、判断することを、含む請求項１～３のいずれか一項に記載の処理方法。
5. 前記運転復帰の判断は、
   前記運転システムの障害が解消し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合に、前記運転システムの前記回復状態への遷移による前記運転復帰の判断をすることを、含む請求項４に記載の処理方法。
6. 前記運転復帰の判断は、
   前記運転システムの障害が解消し且つ前記ホスト移動体におけるオペレータへの引き継ぎの障害が解消した場合にあっても、前記ホスト移動体の外的環境要因により前記運転システムの前記回復状態への遷移が規制される場合に、当該引き継ぎによる前記運転復帰の判断をすることを、含む請求項５に記載の処理方法。
7. 前記運転復帰の判断は、
   前記ホスト移動体におけるオペレータへの引き継ぎに障害が継続し且つ前記運転システムの障害が解消した場合に、前記運転システムの制限された前記回復状態への遷移による前記運転復帰の判断をすることを、含む請求項４に記載の処理方法。
8. 前記運転復帰の報知は、
   前記ホスト移動体外へ送信されることにより前記運転復帰を報知する、報知データを生成することを、含む請求項１～３のいずれか一項に記載の処理方法。
9. 前記運転復帰の報知は、
   前記ホスト移動体と通信する外部センタ（９ａ）から前記ホスト移動体の周囲におけるインフラユニット（９ｂ）へ与えられる制御命令に対して、協調するための前記運転復帰を報知する報知データを、生成することを、含む請求項１～３のいずれか一項に記載の処理方法。
10. 前記運転復帰の報知は、
    前記ホスト移動体外へ視覚刺激可能に出力されることにより前記運転復帰を報知する、報知データを生成することを、含む請求項１～３のいずれか一項に記載の処理方法。
11. 前記運転復帰の報知は、
    前記ホスト移動体外へ聴覚刺激可能に出力されることにより前記運転復帰を報知する、報知データを生成することを、含む請求項１～３のいずれか一項に記載の処理方法。
12. プロセッサ（１２）を有し、ホスト移動体（２）の運転に関する処理を遂行する運転システム（ＤＳ）であって、
    当該運転システムにより緊急操作された前記ホスト移動体の当該緊急操作からの運転復帰を、判断することと、
    前記ホスト移動体外に前記運転復帰を、報知することとを、実行するように構成される運転システム。
13. 運転システム（ＤＳ）においてホスト移動体（２）の運転に関する処理を遂行するために記憶媒体（１０）に記憶され、プロセッサ（１２）により実行される命令を含む処理プログラムであって、
    前記命令は、
    前記運転システムにより緊急操作された前記ホスト移動体の当該緊急操作からの運転復帰を、判断させることと、
    前記ホスト移動体外に前記運転復帰を、報知させることとを、含む処理プログラム。

Images