JP7594979B2 - 車両制御装置および車両制御システム - Google Patents

Description

本発明は車両制御装置および車両制御システムに関する。

車内Ｅ／Ｅ（電気電子）システムにおいて、車両サーバおよびゾーンゲートウェイを用いたアーキテクチャが公知である。このアーキテクチャにより、エンジン、シャーシ、車体、快適性、先進運転支援システム（ＡＤＡＳ）、自動運転（ＡＤ）、等をカバーする広範なアプリケーションが実行される。

車両サーバおよびゾーンゲートウェイは、ＥＣＵ（電子制御装置）を用いて構成される。ＥＣＵのいずれかが障害となった場合に、その障害ＥＣＵがそれまで実行していた機能を、別のＥＣＵが実行する場合がある。特許文献１には、このような技術の例が記載される。

米国特許第９５６３５２３号明細書

しかしながら、従来の技術では、システムコストが高いという課題があった。

たとえば特許文献１では、障害緩和のために主ユニット、副ユニットおよびバックアップユニットがすべて同一のハードウェア資源を備える必要があり、資源要求が最大となる。

本発明はこのような課題を解決するためになされたものであり、障害緩和においてシステムコストをより低減できる技術を提供することを目的とする。

本発明に係る車両制御装置は、
マスターＥＣＵと、１つ以上のクライアントＥＣＵとを備える車両制御装置であって、
前記マスターＥＣＵは、前記クライアントＥＣＵのいずれかの障害を検知した場合に、所定の障害時動作パターンに基づいて安全処理リストを生成して各前記クライアントＥＣＵに送信し、前記安全処理リストは、１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含み、
各前記クライアントＥＣＵは、前記安全処理リストを受信することに応じて、動作モードを通常モードから障害時動作モードに切り替えるとともに、各安全処理を、対応する実行開始期限までに実行開始し、
前記障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成され、
前記障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される。
本発明に係る車両制御システムは、上述の車両制御装置を複数備える。

本発明によれば、障害発生時のＥＣＵ代替動作においてハードウェア資源の利用効率をより高くすることができる。

本発明の実施例１に係る車両制御装置を含む自動運転支援システムに配置される様々なモジュールの例。 実施例１に係る車両制御装置において可能なアーキテクチャの例。 実施例１に係る障害時動作モードの例。 実施例１に係る車両制御装置の構成の例。 実施例１に係る車両制御装置の構成の例。 実施例１に係る車両制御装置の動作の例。 実施例１に係る車両制御装置の動作の例。 実施例１に係るフローチャートの例。 実施例１に係る車両制御装置の動作の例。 実施例１に係る障害時動作パターンの例。 実施例１に係るフローチャートの例。 実施例１に係るバックアップ記憶方式の例。

以下、本発明の実施例を添付図面に基づいて説明する。以下は例示であり、本発明を限定するものではない。

［実施例１］
図１は、本発明の実施例１に係る車両制御装置を含む自動運転支援システムに配置される様々なモジュールの例を示す。実施例１は、車両の自律運転機能を拡張するための、スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションを、車載型ＡＤ／ＡＤＡＳプログラムに統合することができる。

ＡＤとはたとえば自動運転（Autonomous Driving）を意味し、ＡＤＡＳとはたとえば先進運転支援システム（Advanced Driver Assistance System）を意味する。本明細書において、プログラムとは、たとえばアプリケーションプログラムを意味するがこれに限らない。

車載の電気電子（Ｅ／Ｅ）資源の最適な利用のために、および、安全な統合および車載型ＡＤ／ＡＤＡＳ拡張モード遷移のために、車両は車内のＥ／Ｅ資源およびネットワーク資源を実行または導出することができる。

同様に、車両は、環境条件、環境認識アルゴリズム、最適スループット要件、等の動的動作運転設計ドメインの知識ベースを有してもよい。

スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションの資源要件および資源可用性に基づき、実施例１に係る車両制御装置は、要求される資源を安全および最適スループットのために割り当てることができる。

また、アプリケーション要件に基づき、アプリケーションデータのリルーティングおよびスケジューリングも実行される。

自動運転車両は、車両制御システム（たとえばＡＤ／ＡＤＡＳシステム）を用いて制御される。車両制御システムは、ゾーンベースまたはドメインベースのＥ／Ｅアーキテクチャにおいて構成される、複数の環境認識センサ、車両センサ、ローカリゼーションセンサ、アクチュエータ（ブレーキ、ステアリング、スロットル、パワートレイン等）、等を含む。

車両制御システムは、互いに通信する複数のモジュールを含む。複数のモジュールを協働させることが有益である。また、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状態データ、等を要求する複数のプログラムを含む場合がある。モジュールまたはプログラムは、１つ以上の資源要件と、クリティカルな運転シナリオおよび車両制御システム状態における優先度とを有する場合がある。これらのタスクを協働させるには、利用可能な資源の状態に応じて、各タスク／サービスの優先度およびデッドラインを適応させることが有益である。

たとえば、スマートインフラストラクチャまたは路側機クラウドベースリモートサーバと通信可能な車両が、車両制御を支援または完全にテイクオーバできるスマートハイウェイを走行している場合には、車両の自動運転機能を拡張することができる。

クライアントアプリケーションの資源要件によっては、実施例１に係る機能ブロックは、安全なモード遷移のために、クライアントアプリケーションを車載型ＡＤ／ＡＤＡＳアプリケーションに統合することができる。

たとえば、スマートハイウェイが、ハンズフリースーパークルーズおよび車線変更機能を提供可能なハイウェイパイロットラインアプリケーションを提供する場合がある。そのようなシナリオでは、車載側のハンズオン／オフＡＣＣ（適応的クルーズ制御）（半自律運転車両）およびＬＫＡ（車線維持支援）は終了可能である。しかしながら、ＡＥＢ（自動緊急ブレーキ）衝突回避アプリケーション等の安全クリティカルなアプリケーションは、クライアントアプリケーションと協働する必要がある。

このクライアントアプリケーションと、車載型ＡＤ／ＡＤＡＳ安全アプリケーションとの組み合わせでは、リアルタイム／ソフトタイムの遅延制約が厳しくなる場合がある。そのようなシナリオでは、実施例１に係る車両制御装置は、アプリケーションデータのスケジューリングおよびリルーティングも行うことができる。

別の例として、レーダー、ＬｉＤＡＲ、カメラ、等を用いる車両検出は、それぞれ異なるネットワーク帯域幅要件を有する。デッドラインに対してレーダーのネットワーク帯域幅が要求するデータサイズは、カメラの場合に比較してはるかに小さい場合がある。車載型ＡＤ／ＡＤＡＳアプリケーションにスマートインフラストラクチャのクライアントアプリケーションを追加する場合には、ＡＤ／ＡＤＡＳアプリケーションを最小資源要件モードで実行することができる。

同様に、自動停車および最適な電力利用も可能である。フェールオペレーショナルな車両制御システムを装備した高度な自動運転車両では、実施例１に係る車両制御装置は、スマートインフラストラクチャの自律運転能力を利用して、車内の電力消費を抑制することができる。

実施例１に係る車両制御装置は、たとえば自動運転機能を有する自動車に搭載されるが、自動車に搭載されるものに限らない。他の例として、バス、トラック、建設機械、地上型ロボット、倉庫ロボット、飛行機、ヘリコプター、ボート、船舶、農場機械、サービスロボット、列車、ゴルフカート、等にも搭載可能である。

図１は、実施例１に係る車両制御装置を含む自動運転支援システムに配置され得る様々なモジュールの例を示す。この自動運転支援システムは、車両制御装置（たとえば車載型コンピュータシステムを含む）と、車外のコンピュータとを含んで構成される。自動運転車両は、自動モード（通常モード）に設定することができ、安全ドライバーからの支援を得て、または支援なしで、所定の運転シナリオに沿って自動的に車両を運転することができる。

車両制御装置は、環境認識センサシステム１０１と、環境認識システム１０２（運転シナリオに関する情報を収集する）と、計画システム１０３と、無線通信システム１０４と、物理ネットワーク通信システム１０５と、作用システム１０６と、車体・シャーシ制御システム１０７と、インフォテインメントシステム１０８と、ヒューマンマシンインタフェースシステム１０９と、ドライバー監視システム１１０と、車両制御システム１１１と、Ｖ２Ｘシステム１１２と、ドライバーインテンション１１３と、車両診断および機能不全監視システム１１４と、パワートレインシステム１１５とを含む。

自動運転車両は、通常動作モードとして、手動モード、全自動モード、半自動モードのいずれかで走行可能である。車両は、図１のモジュールをすべて備える必要はなく、一部のモジュールが省略されていてもよい。

自動運転車両は、さらに、エンジン、車輪、ハンドル（ステアリングホイール）、トランスミッション、等を備えてもよく、車両制御システムがこれらを制御してもよい。自動運転車両は、さらに、各モジュールが互いに通信することを可能にする物理ネットワーク（有線ネットワーク）または無線ネットワークを備えてもよい。ネットワークは冗長であってもよい。

図２は、実施例１に係る車両制御装置において可能なアーキテクチャの例を示す。車両制御装置は、たとえばセンサ２０１と、ＺＣＵ（ゾーン制御装置）２０２と、ＤＶＣＵ２０３とを備える。センサ２０１はたとえばスマートセンサである。ＤＶＣＵ２０３は、たとえば車両サーバおよびゾーンゲートウェイとして機能する。ＺＣＵ２０２およびＤＶＣＵ２０３は、いずれも１つ以上のＥＣＵ（電子制御装置）を備える。

低ＡＤ（自動運転）グレード（ＳＡＥ規格Ｌ１～Ｌ２）では、単一のＤＶＣＵ２０３のみが設けられる。中間ＡＤグレード（ＳＡＥ規格Ｌ２＋～Ｌ３）では、２つのＤＶＣＵ２０３が設けられる。高ＡＤグレード（ＳＡＥ規格Ｌ４～Ｌ５）では、３つのＤＶＣＵ２０３が設けられる。また、複数のＡＤグレードについて、同一のＤＶＣＵ２０３を再利用することができる。すなわち、車両制御装置のＡＤグレードを更新する際に、それまで使用していたＤＶＣＵ２０３のハードウェアを継続して使用することができる。

実施例１では、すべてのＤＶＣＵ２０３のソフトウェア構成を同一とすることができる。すなわち、いずれかのＤＶＣＵ２０３が実行するプログラムは、他のＤＶＣＵ２０３いずれによっても実行することができる。ただし、１つのプログラムが同時に複数のＤＶＣＵ２０３で実行される必要はない。

このような構成によれば、各センサからの出力がいずれのＤＶＣＵ２０３によっても処理可能となり、車両制御装置の可用性が高まる。

１台の車両に、複数の車両制御装置が搭載されてもよい。これらの車両制御装置は、１つの車両制御システムを構成してもよい。その場合には、車両制御システムは、実施例１に係る車両制御装置を複数備える。たとえば、図１に示すモジュールがそれぞれ車両制御装置を構成し、すべてのモジュールが統合されて車両制御システムを構成してもよい。このようにすると、障害緩和の単位をより自由に設計することができる。

図３は、実施例１に係る障害時動作モード（フェールオペレーショナルモード）の例を示す。図３（ａ）のシナリオでは、車両が通常動作モードで高速道路を走行している。走行中にエラー（たとえばＥＣＵの障害）が検出された場合に、車両が所定の安全停車位置に到着するまで、障害時動作モードにおいて運転が継続される。図３（ｂ）のシナリオでは、自動停車動作の実行中にエラーが検出された場合に、車両が所定の安全停車位置に到着するまで、障害時動作モードにおいて運転が継続される。

通常動作モードおよび障害時動作モードにおける車両制御装置（とくに各ＥＣＵ）の具体的な動作は、当業者公知技術等に基づいて適宜設計可能である。

これらの障害時動作モードにおいて、ＥＣＵの可用性が低いと、高レベルの自動運転が継続できなくなる可能性がある。このため、ＥＣＵの可用性を高め、障害緩和ができるようにすると好適である。

図４は、実施例１に係る車両制御装置の構成の一例を示す。この構成は、複数のＤＶＣＵを備えるハイブリッドゾーンアーキテクチャの例である。車両制御装置は、第１ＤＶＣＵ４０１と、第２ＤＶＣＵ４０２と、第３ＤＶＣＵ４０３とを備える。各ＤＶＣＵは１つ以上のＥＣＵを備える。

ＥＣＵは公知のコンピュータとしてのハードウェア構成を有し、たとえば演算装置および記憶装置を備える。演算装置はたとえばプロセッサを含み、記憶装置はたとえば半導体メモリ装置等の記憶媒体を含む。記憶媒体の一部または全部が、過渡的でない(non-transitory)記憶媒体であってもよい。

ＤＶＣＵのうち１つはマスターＥＣＵを備え、他のＤＶＣＵはクライアントＥＣＵを備える（クライアントＥＣＵは合計で１つ以上である）。図４の例では、第２ＤＶＣＵ４０２がマスターＥＣＵを備え、障害時動作パターン４０４を記憶する。第１ＤＶＣＵ４０１はクライアントＥＣＵを備え、安全処理リスト４０５を記憶することができる。同様に、第３ＤＶＣＵ４０３はクライアントＥＣＵを備え、安全処理リスト４０６を記憶することができる。

ＤＶＣＵは、車両サーバおよびゾーンゲートウェイとして機能する統合ユニットであってもよい。すなわち、マスターＥＣＵおよびクライアントＥＣＵの少なくとも１つは、車両サーバおよびゾーンゲートウェイとして機能する統合ＥＣＵであってもよい。このようにすると、１つのＤＶＣＵで統合された車両Ｅ／Ｅアーキテクチャを実現することができる。

また、車両制御装置は、複数の自動運転グレードに対応するよう構成されてもよい。たとえば、１つ以上のＥＣＵを再利用することにより、図２のように複数の自動運転グレードに対応することができる。このようにすると、車両制御装置の汎用性が高まる。

クライアントＥＣＵのうち少なくとも１つ（この例では第１ＤＶＣＵ４０１のＥＣＵ）は、サブマスターＥＣＵであってもよい。サブマスターＥＣＵは、マスターＥＣＵが障害となった場合に、マスターＥＣＵの動作を代替する。

各ＤＶＣＵの記憶装置は、図示しないプログラムを記憶してもよい。プロセッサがこのプログラムを実行することにより、ＥＣＵは本実施形態において説明される機能を実行してもよい。

また、車両制御装置は、別のＥＣＵ４０７を備え、センサ４０８に接続される。センサ４０８はたとえばスマートセンサである。また、センサ４０８は、たとえば環境認知データを出力する。このような構成によれば、車両制御装置は高度な環境認知処理が可能である。

第１ＤＶＣＵ４０１、第２ＤＶＣＵ４０２、第３ＤＶＣＵ４０３およびＥＣＵ４０７は、直接的に、または他のＤＶＣＵを介して、通信可能に接続される。

図４の例では、各ＤＶＣＵ（マスターＥＣＵおよびクライアントＥＣＵを含む）は、すべて同一のシステムズ・オン・ア・チップ式マイクロコンピュータ４０９によって構成される。このようにするとシステム全体をコンパクトに構成することができるが、同一のシステムズ・オン・ア・チップ式マイクロコンピュータに構成しないことも可能である。

また、各ＤＶＣＵは、障害時アロケーションプログラムおよび／またはランタイム障害緩和プログラムを実行する。障害時アロケーションプログラムの詳細は図８に関連して後述する。ランタイム障害緩和プログラムの詳細は図１１に関連して後述する。

図５は、実施例１に係る車両制御装置の構成の別の一例を示す。この例は純粋なゾーンアーキテクチャであり、車両制御装置は図４のＥＣＵ４０７を備えない。

図６は、実施例１に係る車両制御装置の動作の一例を示す。第１ＤＶＣＵ６０１、第２ＤＶＣＵ６０２、第３ＤＶＣＵ６０３、およびＡＤＡＳ６０４が設けられる。ＡＤＡＳ６０４もまたＥＣＵを備える。第１ＤＶＣＵ６０１、第２ＤＶＣＵ６０２、第３ＤＶＣＵ６０３、およびＡＤＡＳ６０４は、互いに通信可能である。第２ＤＶＣＵ６０２および第３ＤＶＣＵ６０３は、いずれも、パワートレインおよびシャーシ制御を担当してもよい。

車両制御装置は、複数の安全処理（セーフティメカニズム）を実行する。安全処理は、たとえばＡＤ／ＡＤＡＳ機能の一部を構成する。また、安全処理は車両を安全に走行させるための処理であり、ＥＣＵがプログラムを実行することによって安全処理が実行される。

図６の例では、安全処理ＳＭ１およびＳＭ２が実行される。安全処理ＳＭ１はたとえばセンサデータ融合処理（たとえば複数のセンサからの出力を取得して総合的な環境認知を行う処理）であり、安全処理ＳＭ２はたとえば軌跡処理（たとえばアクセル、ブレーキ、操舵等を制御する処理）である。安全処理の具体例は上述のものに限らない。

図６（ａ）～（ｄ）は、それぞれ異なる障害シナリオを示す。図６（ａ）のシナリオでは、通常時にはＡＤＡＳ６０４が安全処理ＳＭ１およびＳＭ２の双方を実行する。ＡＤＡＳ６０４に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１は第２ＤＶＣＵ６０２に移転し、安全処理ＳＭ２は第３ＤＶＣＵ６０３に移転する。この際の具体的な各ＥＣＵの動作（移転先の決定方法を含む）は、図８および図１１等に関連して後述する。

図６（ｂ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第１ＤＶＣＵ６０１に障害が発生した場合、第１ＤＶＣＵ６０１では安全処理ＳＭ１およびＳＭ２のいずれも実行されていないので、安全処理の移転は発生しない。

図６（ｃ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第２ＤＶＣＵ６０２に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１はＡＤＡＳ６０４に移転する。安全処理ＳＭ２は移転しない。

図６（ｄ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第３ＤＶＣＵ６０３に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ２はＡＤＡＳ６０４に移転する。安全処理ＳＭ１は移転しない。

図７は、実施例１に係る車両制御装置の動作の別の一例を示す。この例は純粋なゾーンアーキテクチャであり、車両制御装置は図６のＡＤＡＳ６０４を備えない。図７の例では、さらに安全処理ＳＭ３が実行される。安全処理ＳＭ３はたとえばＡＣＣ（適応的クルーズ制御）処理である。

図７（ａ）～（ｃ）のシナリオにおいて、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２およびＳＭ３を実行する。

図７（ａ）のシナリオにおいて、第１ＤＶＣＵ６０１に障害が発生した場合、第１ＤＶＣＵ６０１では安全処理ＳＭ１～ＳＭ３のいずれも実行されていないので、安全処理の移転は発生しない。

図７（ｂ）のシナリオにおいて、第２ＤＶＣＵ６０２に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１は第１ＤＶＣＵ６０１に移転する。安全処理ＳＭ２およびＳＭ３は移転しない。

図７（ｃ）のシナリオにおいて、第３ＤＶＣＵ６０３に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ２は第１ＤＶＣＵ６０１に移転し、安全処理ＳＭ３は第２ＤＶＣＵ６０２に移転する。

図６および図７に示すように、各ＥＣＵは、自身が通常実行する安全処理に限らず、他のＥＣＵが通常実行する安全処理も、実行可能である。とくに、マスターＥＣＵおよびクライアントＥＣＵのいずれもが、すべての安全処理を実行可能であるように構成すると、各ＥＣＵの汎用性が高まり好適である。なお、各安全処理は、状況に応じて分散実行することができ、１つのＥＣＵがすべての安全処理を同時に実行する必要はない。

図８は、実施例１に係るフローチャートの一例を示す。このフローチャートは、障害時アロケーションプログラムの動作を説明する。このフローチャートは、マスターＥＣＵおよびクライアントＥＣＵが、それぞれ対応する障害時アロケーションモジュール（障害時アロケーションプログラム）を実行することにより実行される。

マスターＥＣＵは、クライアントＥＣＵのいずれかの障害を検知することができる。マスターＥＣＵは、クライアントＥＣＵを監視し、クライアントＥＣＵのいずれかの障害を検知した場合に、未処理の障害時動作パターンがあるか否かを判定する（Ｓ１）。所定の障害時動作パターンの例は、図１０等を用いて後述する。

未処理の障害時動作パターンがなければ（すなわち、障害時動作パターンがないか、または検知された障害時動作パターンがすべて図８のフローチャートに従って処理済みであれば）、図８の処理は終了される。

未処理の障害時動作パターンがあれば（たとえばクライアントＥＣＵの障害が検知された直後）、マスターＥＣＵは、障害時動作パターンに基づいて安全処理リストを生成し、各クライアントＥＣＵに送信する（Ｓ２）。

図１０に、実施例１に係る障害時動作パターンの例を示す。図１０（ａ）は障害時動作パターンを示し、障害となったＥＣＵを識別する情報と、当該ＥＣＵが障害となった場合の障害時動作モードを識別する情報と、当該ＥＣＵで実行されていた安全処理の移転先となる別のＥＣＵを識別する情報とを関連付ける。このような障害時動作パターンは、事前に（たとえば設計段階において）定義することができる。マスターＥＣＵの記憶装置は、この障害時動作パターンを記憶する。

たとえば、ＡＤを担当するクライアントＥＣＵが障害となった場合には、安全処理ＳＭ１は第１ＤＶＣＵのクライアントＥＣＵに移転し、安全処理ＳＭ２は第２ＤＶＣＵのクライアントＥＣＵに移転する。

障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成される。たとえば、設計段階において、各クライアントＥＣＵについて、そのクライアントＥＣＵが通常動作モードにおいて実行するすべてのソフトウェアに加え、同時に実行する可能性のある安全処理をすべて同時に実行した場合に、そのクライアントＥＣＵのメモリ容量が不足しないように、障害時動作パターンを設計することができる。

また、障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される。たとえば図１０の例では、第１ＤＶＣＵおよび第２ＤＶＣＵに割り当てられる安全処理は互いに異なっている。とくに、同一の安全処理が複数のクライアントＥＣＵにアロケーションされないように、すなわち、同一の安全処理が複数のクライアントＥＣＵの記憶装置（たとえば主記憶装置）に同時には記憶されないようにすると、ハードウェア資源が低減でき好適である。

図１０（ｂ）は実行開始期限を示し、各安全処理が移転先のクライアントＥＣＵにおいて実行開始されるまでの期限（実行開始期限）を表す。このような実行開始期限は、事前に（たとえば設計段階において）定義することができる。マスターＥＣＵの記憶装置は、この実行開始期限を記憶する。

各クライアントＥＣＵに送信される安全処理リストは、各クライアントＥＣＵにおいて実行開始すべき１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含む。たとえば、図１０の例において、ＡＤを担当するＥＣＵが障害となった場合には、第１ＤＶＣＵのＥＣＵに対して、安全処理ＳＭ１の実行を開始すべきであるということと、その実行開始期限は１００ｍｓであるということとを示す安全処理リストが送信される。同様に、第２ＤＶＣＵのＥＣＵに対して、安全処理ＳＭ２の実行を開始すべきであるということと、その実行開始期限は１００ｍｓであるということとを示す安全処理リストが送信される。

実行開始期限の計測開始タイミングは適宜設計可能である。たとえば、マスターＥＣＵが障害を検知した時刻としてもよいし、マスターＥＣＵが安全処理リストを送信した時刻としてもよいし、他の時刻としてもよい。

クライアントＥＣＵは、安全処理リストを受信することに応じて、動作モードを通常動作モードから障害時動作モード（たとえば図３に関連して説明したもの）に切り替える。なお、マスターＥＣＵも同様に、安全処理リストの送信に際して、動作モードを通常動作モードから障害時動作モードに切り替えてもよい。

そして、クライアントＥＣＵは、安全処理リストに含まれる安全処理のうち、すでに実行中であるものを処理対象から除外する（Ｓ３）。「処理対象」とは、ここでは後述のＳ４およびＳ５の処理の対象となるものを意味する。このような除外により、安全処理の重複実行が防止され、低ハードウェア資源のＥＣＵを有効に利用することができる。

次に、クライアントＥＣＵは、未実行の安全処理があるか否かを判定する（Ｓ４）。安全処理リストに含まれる安全処理がすべて実行開始済みであれば、処理はＳ１に戻る。

未実行の安全処理があれば、クライアントＥＣＵはその安全処理の実行を開始する（Ｓ５）。この際、クライアントＥＣＵは、各安全処理を、対応する実行開始期限までに実行開始する。クライアントＥＣＵは、指示された安全処理のそれぞれについて、その安全処理の実行を開始した後に、その安全処理の実行開始が完了したことを示す通知（安全処理実行開始完了通知）を、マスターＥＣＵに送信してもよい。その後、処理はＳ１に戻る。

図９は、図８のような処理によって実現される、実施例１に係る車両制御装置の動作の一例を示す。図９（ａ）は通常動作モードを示す。車両制御装置は第１ＤＶＣＵ９０１、第２ＤＶＣＵ９０２、第３ＤＶＣＵ９０３、ＥＣＵ９０７、センサ９０８を備える。第２ＤＶＣＵ９０２はマスターＥＣＵを備え、障害時動作パターン９０４を記憶する。第１ＤＶＣＵ９０１および第３ＤＶＣＵ９０３はクライアントＥＣＵを備える。

この例では、ＥＣＵ９０７が障害となったとする。図９（ｂ）は障害時動作モードを示す。第２ＤＶＣＵ９０２（厳密にはマスターＥＣＵ）は、ＥＣＵ９０７の障害を検知し、安全処理リスト９０５を第１ＤＶＣＵ９０１に送信し、安全処理リスト９０６を第３ＤＶＣＵ９０３に送信する。第１ＤＶＣＵ９０１は安全処理リスト９０５を記憶し、第３ＤＶＣＵ９０３は安全処理リスト９０６を記憶する。第１ＤＶＣＵ９０１および第３ＤＶＣＵ９０３は、それぞれ安全処理リスト９０５および９０６に従って安全処理を実行する。

このように、実施例１に係る車両制御装置によれば、障害時動作パターンを適切に設計することにより、安全処理を各ＥＣＵのハードウェア資源に応じて移転させることができ、また、安全処理の重複が発生しないので、障害発生時のＥＣＵ代替動作においてハードウェア資源の利用効率をより高くすることができる。

なお、図８の処理は、マスターＥＣＵが障害となった場合には実行できない可能性がある。クライアントＥＣＵのいずれかがサブマスターＥＣＵである場合には、サブマスターＥＣＵがマスターＥＣＵに代わって図８の処理を実行するように構成してもよい。すなわち、サブマスターＥＣＵは、マスターＥＣＵの障害を検知した場合に、安全処理リストを生成して他の各クライアントＥＣＵに送信してもよい。このような構成によれば、マスターＥＣＵを含むすべてのＥＣＵの障害に対応することができる。

図１１は、実施例１に係るフローチャートの別の一例を示す。このフローチャートは、ランタイム障害緩和プログラムの動作を説明する。このフローチャートは、マスターＥＣＵおよびクライアントＥＣＵが、それぞれ対応する障害緩和モジュール（障害緩和プログラム）を実行することにより実行される。

マスターＥＣＵは、クライアントＥＣＵの障害を検知したか否かを判定する（Ｓ１１）。障害を検知していない場合、Ｓ１１を繰り返す。障害を検知した場合に、障害となったクライアントＥＣＵに応じて障害時動作パターンを選択する（Ｓ１２）。たとえば図１０の例において、ＡＤを担当するＥＣＵが障害となった場合には、障害時動作モード「１」に対応する障害時動作パターンが選択される。

次に、マスターＥＣＵは、選択した障害時動作パターンに従って安全処理リストを作成し、各クライアントＥＣＵに送信する（Ｓ１３）。この処理は、たとえば図８のＳ２と同様に行われる。次に、マスターＥＣＵは、動作モードを通常動作モードから障害時動作モードに切り替える（Ｓ１４）。なお、クライアントＥＣＵも同様に、安全処理リストを受信することに応じて、運転動作モードを通常動作モードから障害時動作モードに切り替えてもよい。

図１１には示さないが、各クライアントＥＣＵは、図８のＳ３～Ｓ５の処理を実行することにより、安全処理の実行を開始し、安全処理実行開始完了通知をマスターＥＣＵに送信する。マスターＥＣＵは、各クライアントＥＣＵからの安全処理実行開始完了通知を待機し、これを受信する（Ｓ１５）。

マスターＥＣＵは、すべての安全処理について、対応する実行開始期限までに、安全処理実行開始完了通知を受信したか否かを判定する（Ｓ１６）。すべての安全処理について、対応する実行開始期限までに、安全処理実行開始完了通知を受信した場合には、マスターＥＣＵは、障害時動作モードで動作を継続し（Ｓ１７）、図１１の処理を終了する。

そうでない場合（すなわち、いずれかの安全処理について、対応する実行開始期限までに安全処理実行開始完了通知を受信しなかった場合。これは、いずれかの安全処理について、安全処理実行開始完了通知を受信しなかった場合、および、いずれかの安全処理について、安全処理実行開始完了通知の受信が、対応する実行開始期限を過ぎた場合を含む）には、車両制御装置の動作モードを障害時動作モードから障害時安全モード（フェールセーフモード）に切り替える（Ｓ１８）。

障害時安全モードの具体的な動作内容は、当業者が公知技術等に基づいて適宜設計可能であるが、たとえば、搭乗者に対する運転のテイクオーバ要請を行ってもよい。このようにすると、安全処理の実行開始が適切に行われなかった場合でも安全な対応をとることができる。

図１２は、実施例１に係るバックアップ記憶方式の例を示す。車両制御装置は、マスターＥＣＵおよびクライアントＥＣＵによって実行されるすべてのソフトウェア（各安全処理を含む）のバックアップを記憶する記憶装置を備えてもよい。

図１２（ａ）は集中方式を示す。車両制御装置は、記憶装置１２０３を備える。記憶装置１２０３は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２のすべてからアクセス可能である。記憶装置１２０３は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２によって実行されるすべてのソフトウェア（安全処理ＳＭ１およびＳＭ２を含む）について、バイナリファイル（実行可能形式のファイル）のコピーを記憶する。

図１２（ｂ）は分散方式を示す。車両制御装置は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２によって実行されるすべてのソフトウェアについて、バイナリファイルのコピーを、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２のそれぞれの記憶装置（たとえば主記憶装置）に分散させて記憶する。この例では、通常時にはマスターＥＣＵ１２０１は安全処理ＳＭ１を実行しており、障害時動作モードにおいてさらに安全処理ＳＭ２を実行することができる。

１０１…環境認識センサシステム
１０２…環境認識システム
１０３…計画システム
１０４…無線通信システム
１０５…物理ネットワーク通信システム
１０６…作用システム
１０７…車体・シャーシ制御システム
１０８…インフォテインメントシステム
１０９…ヒューマンマシンインタフェースシステム
１１０…ドライバー監視システム
１１１…車両制御システム
１１２…Ｖ２Ｘシステム
１１３…ドライバーインテンション
１１４…機能不全監視システム
１１５…パワートレインシステム
２０１…センサ
２０２…ＺＣＵ
２０３…ＤＶＣＵ
４０１…第１ＤＶＣＵ
４０２…第２ＤＶＣＵ
４０３…第３ＤＶＣＵ
４０４…障害時動作パターン
４０５…安全処理リスト
４０６…安全処理リスト
４０７…ＥＣＵ
４０８…センサ
４０９…システムズ・オン・ア・チップ式マイクロコンピュータ
６０１…第１ＤＶＣＵ
６０２…第２ＤＶＣＵ
６０３…第３ＤＶＣＵ
６０４…ＡＤＡＳ
９０１…第１ＤＶＣＵ
９０２…第２ＤＶＣＵ
９０３…第３ＤＶＣＵ
９０４…障害時動作パターン
９０５…安全処理リスト
９０６…安全処理リスト
９０７…ＥＣＵ
９０８…センサ
ＳＭ１…安全処理
ＳＭ２…安全処理
ＳＭ３…安全処理
１２０１…マスターＥＣＵ
１２０２…クライアントＥＣＵ
１２０３…記憶装置

Claims (11)

1. マスターＥＣＵと、１つ以上のクライアントＥＣＵとを備える車両制御装置であって、
   前記マスターＥＣＵは、前記クライアントＥＣＵのいずれかの障害を検知した場合に、所定の障害時動作パターンに基づいて安全処理リストを生成して各前記クライアントＥＣＵに送信し、前記安全処理リストは、１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含み、
   各前記クライアントＥＣＵは、前記安全処理リストを受信することに応じて、動作モードを通常モードから障害時動作モードに切り替えるとともに、各安全処理を、対応する実行開始期限までに実行開始し、
   前記障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成され、
   前記障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される、
   車両制御装置。
2. 各前記クライアントＥＣＵは、各安全処理について、その安全処理の実行を開始した後に、安全処理実行開始完了通知を前記マスターＥＣＵに送信し、
   前記マスターＥＣＵは、すべての安全処理について対応する実行開始期限までに前記安全処理実行開始完了通知を受信した場合には、前記障害時動作モードにおける動作を継続し、いずれかの安全処理について対応する実行開始期限までに前記安全処理実行開始完了通知を受信しなかった場合には、動作モードを障害時安全モードに切り替える、
   請求項１に記載の車両制御装置。
3. 前記マスターＥＣＵおよび各前記クライアントＥＣＵは、すべて同一のシステムズ・オン・ア・チップ式マイクロコンピュータによって構成される、請求項１に記載の車両制御装置。
4. 前記１つ以上のクライアントＥＣＵのうち少なくとも１つは、サブマスターＥＣＵであり、
   前記サブマスターＥＣＵは、前記マスターＥＣＵの障害を検知した場合に、前記安全処理リストを生成して他の各クライアントＥＣＵに送信する、
   請求項１に記載の車両制御装置。
5. 請求項１に記載の車両制御装置を複数備える、車両制御システム。
6. 前記マスターＥＣＵおよび前記クライアントＥＣＵの少なくとも１つは、車両サーバおよびゾーンゲートウェイとして機能する統合ＥＣＵである、
   請求項１に記載の車両制御装置。
7. 前記車両制御装置は、複数の自動運転グレードに対応する、
   請求項６に記載の車両制御装置。
8. 前記車両制御装置は、環境認知データを出力するスマートセンサに接続される、
   請求項１に記載の車両制御装置。
9. 前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵは、いずれも、すべての前記安全処理を実行可能であるように構成される、
   請求項１に記載の車両制御装置。
10. 前記車両制御装置は、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵによって実行されるすべてのソフトウェアのバックアップを記憶する記憶装置を備える、
    請求項１に記載の車両制御装置。
11. 前記車両制御装置は、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵによって実行されるすべてのソフトウェアについて、バイナリファイルのコピーを、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵのすべてからアクセス可能な記憶装置に記憶するか、または、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵのそれぞれの記憶装置に分散させて記憶する、
    請求項１に記載の車両制御装置。
    

Images