JP2020052479A - 車両用制御装置および車両制御方法 - Google Patents

Abstract

【課題】認知・判断処理を行うフロントエンドのＣＰＵが故障した際に、安定した車両の自動制御を継続できる制御装置を提供する。【解決手段】制御装置１００は、車両周辺の物体を検知するためのセンサ情報を処理するフロントエンドＣＰＵ（ＦＥ−ＣＰＵ）１０１と、ＦＥ−ＣＰＵ１０１によるセンサ情報の処理結果に基づいて、車両のアクチュエータの制御情報を生成するバックエンドＣＰＵ（ＢＥ−ＣＰＵ）１０３と、処理ロジックを動的に変更可能なプログラマブルロジックデバイス（ＰＬＤ）１０２とを備える。ＦＥ−ＣＰＵ１０１の故障が検出されると、ＰＬＤ１０２に、ＦＥ−ＣＰＵ１０１の代わりにセンサ情報を処理する処理ロジックが構成され、ＢＥ−ＣＰＵ１０３は、ＰＬＤ１０２によるセンサ情報の処理結果に基づいて、アクチュエータの制御情報を生成する。【選択図】図１

Description

本発明は、主に車両の走行制御に用いられる制御装置に関する。

車両の自動運転機能や予防安全機能に用いられる制御装置は、車両に搭載された複数のセンサＥＣＵ（Electronic Control Unit）から車両周辺の物体（他の車両を含む）の位置、移動方向、信頼度などの情報を含むセンサ情報を取得し、（Ａ）複数のセンサ情報に基づいて、車両を基準とする各物体の位置、移動方向、速度などの状況を算出し、（Ｂ）各物体の状況に基づいて、車両の目標経路（自車がとるべき経路および速度）を算出する。また、制御装置は、（Ｃ）目標経路と車両の動作状況とから、車両が安定性を保ちつつ目的の挙動を行うように制御するための制御量を算出し、算出した制御量を車両が搭載する各種のアクチュエータＥＣＵに伝達する。これら一連の処理において、処理（Ａ）を「認知」、処理（Ｂ）を「判断」、処理（Ｃ）を「操作」と呼ぶものとする。

上記の認知・判断処理においては、大量のデータを処理する必要があり、その処理量は検知された物体の個数に応じて級数的に増大する。このため、認知・判断処理は、処理性能の高いＣＰＵ（Central Processing Unit）に加え、ハードウェア（ＨＷ）アクセラレータを用いて行われる。また、操作処理においては、車両を安全に制御すると共に、確実に制御情報をアクチュエータに伝達する必要がある。このため、操作処理は、信頼性の高いＣＰＵを用いて行われる。以降、制御装置における認知・判断処理を担当する部分をフロントエンド（以降「ＦＥ」）と呼び、操作処理を担当する部分をバックエンド（以降「ＢＥ」）と呼ぶ。

このように、車両の動作を自動制御する制御装置において、ＦＥは、処理能力が高い高性能ＣＰＵ等が用いられるので、消費電力が大きくなるとともに、ハードウェアが高価になる。そのためＦＥは、信頼性を向上させるために多重化することが難しい。一方、ＢＥは、車両の操作を司る部分であり高い信頼性が求められるので、多重化したＣＰＵを用いる他、メモリをＩＣチップ内に内蔵するなどした信頼性の高いハードウェアが用いられる。そのため、ＢＥは、消費電力を低くする観点から、高性能なＣＰＵを用いることができない。従って、ＦＥのハードウェア故障、或いは、ＦＥのＣＰＵで動作するソフトウェアの異常により、制御装置が動作を継続できない状態となった場合、ＢＥ等でＦＥの処理を停止させ、緊急処理としてＢＥで自動制御を継続することで、車両を安全な状態で停止させる必要がある。

しかしながら、ＢＥのＣＰＵはＦＥのＣＰＵに比べて処理能力が低いため、ＦＥで実行していた高度な認知・判断処理をＢＥのＣＰＵでは十分な処理を行うことができないという問題が有る。

この問題への対策として、例えば下記の特許文献１には、制御装置の演算能力が不足する状況になると、他の制御ＥＣＵにソフトウェア処理を分散することで、制御装置の処理負荷の軽減を図る技術が提案されている。また、制御装置にハードウェア故障が生じたときに他の装置が代替して処理を継続する技術（例えば、特許文献２）や、ＥＣＵの故障が生じたときに共用のバックアップＥＣＵがソフトウェア処理を引き継ぐことで動作を継続する技術（例えば、特許文献３）なども知られている。

特開２０１５−２１９５８６号公報 国際公開第２０１１／０８７０２０号 特許第６１８９００４号公報

特許文献１の技術では、制御装置が通信バスを介して複数のＥＣＵへ処理要求を行う必要があるため、信頼性が必要な緊急処理における実時間応答性が問題となる。また、特許文献２，３の技術では、制御装置専用のハードウェアやＥＣＵが行っていた処理を、他の用途で用いられていた装置およびＥＣＵが代替して処理することになるため、処理機能の低下が避けられない他、高い信頼性が要求される操作処理には利用できないという問題がある。

本発明は上記のような問題を解決するためになされたものであり、認知・判断処理を行うフロントエンドのＣＰＵが故障した際に、安定した車両の自動制御を継続できる制御装置を提供することを目的とする。

本発明に係る車両用制御装置は、車両周辺の物体を検知するためのセンサ情報を処理するフロントエンドＣＰＵと、前記フロントエンドＣＰＵによる前記センサ情報の処理結果に基づいて、前記車両のアクチュエータの制御情報を生成するバックエンドＣＰＵと、処理ロジックを動的に変更可能なプログラマブルロジックデバイスと、を備え、前記フロントエンドＣＰＵの故障が検出されると、前記プログラマブルロジックデバイスに、前記フロントエンドＣＰＵの代わりに前記センサ情報を処理する処理ロジックが構成され、前記バックエンドＣＰＵは、前記プログラマブルロジックデバイスによる前記センサ情報の処理結果に基づいて、前記アクチュエータの前記制御情報を生成する。

本発明に係る制御装置によれば、フロントエンドＣＰＵが故障により利用できない状態になると、フロントエンドＣＰＵが行っていた認知・判断処理の代替処理をＰＬＤに構成された処理ロジックで行い、バックエンドＣＰＵとＰＬＤとが連携して動作することにより、自車両の走行制御を継続することができる。また、フロントエンドＣＰＵが正常に動作するときには、ＰＬＤの処理ロジックで、フロントエンドＣＰＵのソフトウェア処理を補助して、フロントエンドＣＰＵの処理負荷を軽減できる。つまり、ＰＬＤの処理ロジックが、フロントエンドＣＰＵのソフトウェア処理の一部を分担することで、システム全体の処理性能を向上させることができる。

本発明の実施の形態１および実施の形態２に係る制御装置の構成を示すブロック図である。 実施の形態１、実施の形態２および実施の形態３におけるバックエンドＣＰＵの定常動作（ＢＥ定常動作）を示すフローチャートである。 実施の形態１において、フロントエンドＣＰＵの故障が検出された後のバックエンドＣＰＵ１０３の動作（ＦＥ故障時ＢＥ動作）を示すフローチャートである。 実施の形態１、実施の形態２および実施の形態３におけるフロントエンドＣＰＵの定常動作（ＦＥ定常動作）を示すフローチャートである。 実施の形態１において、フロントエンドＣＰＵの故障が検出された後のフロントエンドＣＰＵの動作（ＦＥ故障時動作）を示すフローチャートである。 実施の形態１、実施の形態２および実施の形態３におけるＰＬＤの動作を示すフローチャートである。 変形例２に係る制御装置の構成を示すブロック図である。 実施の形態２において、フロントエンドＣＰＵの故障が検出された後のバックエンドＣＰＵ１０３の動作（ＦＥ故障時ＢＥ動作）を示すフローチャートである。 実施の形態２において、フロントエンドＣＰＵの故障が検出された後のフロントエンドＣＰＵの動作（ＦＥ故障時動作）を示すフローチャートである。 本発明の実施の形態３に係る制御装置の構成を示すブロック図である。

＜実施の形態１＞
図１は、実施の形態１に係る車両用制御装置（以降、単に「制御装置」と称す）１００の構成を示すブロック図である。制御装置１００は、当該制御装置１００を搭載する車両の自動運転制御等を行うものである。以降、制御装置１００を搭載する車両を「自車両」という。

制御装置１００は、自車両のセンサＥＣＵ１０９およびセンサＥＣＵ１０９と共に車載ネットワーク１０８に接続されている。

センサＥＣＵ１０９は、自車両に搭載されたカメラ、ソナー、ミリ波センサ、レーザセンサといった自車両周囲の物体を検出するセンサの状態、ならびに、自車両の速度、加速度、旋回角および旋回角速度や灯火状態など、自車両に動作状態を検出するセンサの状態を検知するＥＣＵである。

アクチュエータＥＣＵ１１０は、自車両に搭載されたアクセル、ブレーキ、エンジン、ライトといったアクチュエータを制御するＥＣＵである。

制御装置１００は、センサＥＣＵ１０９から、自車両周辺の物体（他の車両を含む）を検知するためのセンサ情報（車両周辺の物体の位置、移動方向、信頼度などの情報）を取得し、当該センサ情報を処理して、その処理結果から算出される制御情報をアクチュエータＥＣＵ１１０へ入力することで、自車両を制御する。

車載ネットワーク１０８は、自車両に搭載されるＥＣＵを互いに接続するネットワークであり、具体例としてはＣＡＮ（Controller Area Network）がある。また、車載ネットワーク１０８は、Ethernet（登録商標）、ＭＯＳＴ（Media Oriented Systems Transport）（登録商標）、ＬＩＮ（Local Interconnect Network）、FlexRay（登録商標）などの通信ネットワークであってもよい。

制御装置１００は、フロントエンドＣＰＵ（以降「ＦＥ−ＣＰＵ」）１０１、プログラマブルロジックデバイス（以降「ＰＬＤ」）１０２、バックエンドＣＰＵ（以降「ＢＥ−ＣＰＵ」）１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５および通信インタフェース（以降「通信ＩＦ」）１０６を備えている。ＦＥ−ＣＰＵ１０１、ＰＬＤ１０２、ＢＥ−ＣＰＵ１０３、ＲＡＭ１０４および通信ＩＦ１０６は、内部バス１０７を通して相互接続されている。

ＦＥ−ＣＰＵ１０１は、処理能力が高く、高度な演算処理を扱うプロセッサであり、主に自車両の制御に係る「認知」および「判断」の処理を行う。ＢＥ−ＣＰＵ１０３は、信頼性が高く故障に対して耐性を持つプロセッサであり、主に自車両の制御に係る「操作」の処理を行う。ＦＥ−ＣＰＵ１０１およびＢＥ−ＣＰＵ１０３は、各種の演算処理を行うＩＣ（Integrated Circuit）であり、より具体的には、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）など、ソフトウェアを実行する半導体デバイスである。

ＰＬＤ１０２は、プログラム可能なハードウェア処理装置である。すなわち、ＰＬＤ１０２は、処理ロジック（ハードウェアロジック）をハードウェアで処理するデバイスであり、ＰＬＤ１０２の内部に構成される処理ロジックは、ＰＬＤ１０２に外部から処理モジュールとして供給することで、動的に変更することができる。より具体的には、ＰＬＤ１０２は、例えばＦＰＧＡ（Field Programmable Gate Array）等の半導体デバイスである。ＦＰＧＡの処理ロジックは、高位合成と呼ばれる技術によりＣＰＵで実行するソフトウェアと同様の言語体系で設計できる。また、一つの処理を、ＣＰＵで実行するソフトウェアと、ＦＰＧＡで実行する処理ロジックとに分割したり、同様の処理を、ＣＰＵ用のソフトウェアと、ＦＰＧＡ用の処理ロジックとの両方で実現したりすることもできる。

ＲＡＭ１０４は、ＦＥ−ＣＰＵ１０１の一時記憶装置として使用される。

ＲＯＭ１０５は、ＦＥ−ＣＰＵ１０１およびＢＥ−ＣＰＵ１０３で実行されるプログラムおよびＰＬＤ１０２で実行される処理ロジックのそれぞれを、処理モジュールとして記憶している。ＲＯＭ１０５の具体例としては、フラッシュメモリがある。また、ＲＯＭ１０５は、ＳＤ（Secure Digital）メモリカード、ＣＦ（CompactFlash（登録商標））、ＨＤＤ（Hard Disk Drive）、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤといった可搬記憶媒体であってもよい。

通信ＩＦ１０６は、制御装置１００が車載ネットワーク１０８との通信を行うための手段である。

図１に示すように、ＲＯＭ１０５には、ＦＥ−ＣＰＵ１０１で実行される処理モジュール（プログラム）である認知処理モジュール２１１ｍ、判断処理モジュール２１２ｍおよびＦＥ診断モジュール２１３ｍと、ＰＬＤ１０２で実行される処理モジュール（処理ロジック）である高度演算処理モジュール２２１ｍおよびＢＥ支援処理モジュール２２２ｍとが記憶されている。なお、ＢＥ−ＣＰＵ１０３で実行される処理モジュール（プログラム）もＲＯＭ１０５に記憶されていてもよいが、本実施の形態では、ＢＥ−ＣＰＵ１０３の信頼性確保の観点から、ＢＥ−ＣＰＵ１０３は、処理モジュールを記憶したメモリ（不図示）を内蔵しているものとする。

ＦＥ−ＣＰＵ１０１は、ＲＯＭ１０５から認知処理モジュール２１１ｍ、判断処理モジュール２１２ｍおよびＦＥ診断モジュール２１３ｍを読み出して実行することで、認知処理部２１１、判断処理部２１２およびＦＥ診断部２１３を実現する。ＰＬＤ１０２は、ＲＯＭ１０５から高度演算処理モジュール２２１ｍおよびＢＥ支援処理モジュール２２２ｍを読み出して実行することで、高度演算処理部２２１およびＢＥ支援処理部２２２を実現する。ＢＥ−ＣＰＵ１０３は、内蔵メモリからプログラムを読み出して実行することで、操作処理部２３１、通信処理部２３２、ＦＥ故障判定部２３３、ＰＬＤ更新処理部２３４およびＰＬＤ制御部２３５を実現する。

ＦＥ−ＣＰＵ１０１の認知処理部２１１は、センサＥＣＵ１０９から出力されるセンサ情報に基づいて、自車両周辺の物体（他の車両を含む）の状況を把握する「認知」の処理を行う。すなわち、認知処理部２１１は、センサ情報に含まれる自車両周辺の物体の位置、移動方向、信頼度などの情報から、車両を基準とする各物体の位置、移動方向、速度などの状況を把握する。

ＦＥ−ＣＰＵ１０１の判断処理部２１２は、認知処理で把握した自車両周辺の物体の状況に基づいて、自車両の目標経路を算出する「判断」の処理を行う。なお、「目標経路」には、自車両が走行すべき経路とその経路を走行するときに自車両がとるべき速度の情報が含まれる。

ＦＥ−ＣＰＵ１０１のＦＥ診断部２１３は、システムの起動時などに、ＦＥ−ＣＰＵ１０１が正常に動作できるかどうかの自己診断を行う。

ＰＬＤ１０２の高度演算処理部２２１は、ＦＥ−ＣＰＵ１０１の認知処理部２１１および判断処理部２１２の処理の一部を分担することで、ＦＥ−ＣＰＵ１０１の処理負荷を軽減させ、システム全体の処理性能を向上させる。例えば、高度演算処理部２２１は、センサＥＣＵ１０９により検知された物体の個数が多いときなど、認知・判断処理の負荷が増大してソフトウェア処理では処理能力が不足する場合に、認知処理部２１１と同様に自車両周辺の物体の状況を把握する認知処理を行ったり、判断処理部２１２が行う判断処理の一部を行ったりすることで、ＦＥ−ＣＰＵ１０１の動作を補助する。なお、認知処理部２１１が行う認知処理と、高度演算処理部２２１が行う認知処理とは、互いに異なるセンサ情報を処理するものであってもよいし、互いに連携して同じセンサ情報を処理するものであってもよい。

ＰＬＤ１０２のＢＥ支援処理部２２２は、ＦＥ−ＣＰＵ１０１が故障したときに、ＢＥ−ＣＰＵ１０３の動作を支援する処理を行う処理ロジックである。ＢＥ支援処理部２２２は、ＦＥ−ＣＰＵ１０１が故障したときに、高度演算処理部２２１と連携して、ＦＥ−ＣＰＵ１０１の代替として機能するように、認知処理部２１１および判断処理部２１２が行っていた処理の一部を実行する。ＢＥ支援処理部２２２はＦＥ−ＣＰＵ１０１が正常に動作しているときには構成されている必要はなく、少なくともＦＥ−ＣＰＵ１０１が故障したときに構成されればよい。なお、「故障」には、ハードウェア故障だけでなく、ソフトウェアの異常により動作を継続できなくなった状態も含まれる。

ＢＥ−ＣＰＵ１０３の操作処理部２３１は、ＦＥ−ＣＰＵ１０１の判断処理部２１２が算出した目標経路に基づいて、自車両を目標経路に従って走行させるためのアクチュエータの制御量を算出し、算出した制御量を示す制御情報をアクチュエータＥＣＵ１１０へ伝達する「操作」の処理を行う。

ＢＥ−ＣＰＵ１０３の通信処理部２３２は、通信ＩＦ１０６を用いてセンサＥＣＵ１０９やアクチュエータＥＣＵ１１０との通信を行う。例えば、アクチュエータＥＣＵ１１０が出力するセンサ情報は、通信処理部２３２を通してＦＥ−ＣＰＵ１０１の認知処理部２１１に入力される。また、ＢＥ−ＣＰＵ１０３の操作処理部２３１が生成した制御情報は、通信処理部２３２を通してアクチュエータＥＣＵ１１０に伝達される。

ＢＥ−ＣＰＵ１０３のＦＥ故障判定部２３３は、ＦＥ−ＣＰＵ１０１の処理結果（判断処理部２１２が算出した目標経路など）を監視して、ＦＥ−ＣＰＵ１０１の処理結果に異常が生じたとき、ＦＥ−ＣＰＵ１０１の故障を検出するための故障診断を行う。例えば、ＦＥ−ＣＰＵ１０１の出力値が定常範囲を超えたり、ＦＥ−ＣＰＵ１０１の出力周期が定常動作と異なったりする異常が確認されたときに、ＦＥ故障判定部２３３はＦＥ−ＣＰＵ１０１の故障診断を行う。故障診断の結果、ＦＥ−ＣＰＵ１０１の故障が検出されると、ＦＥ故障判定部２３３は、ＦＥ−ＣＰＵ１０１へ停止指示を出すと共に、ＦＥ−ＣＰＵ１０１の出力を無効として扱うように、ＦＥ−ＣＰＵ１０１を処理系から切り離す。故障診断の方法は、ＦＥ−ＣＰＵ１０１に試験用データを供給し、その応答としてのＦＥ−ＣＰＵ１０１の出力結果を確認する方法など、一般的な方法でよい。

ＢＥ−ＣＰＵ１０３のＰＬＤ更新処理部２３４は、ＰＬＤ１０２に構成される処理ロジックの更新処理を行う。ＰＬＤ更新処理部２３４は、例えばＦＥ故障判定部２３３によってＦＥ−ＣＰＵ１０１の故障が検出されたときに、ＲＯＭ１０５に記憶されているＢＥ支援処理モジュール２２２ｍをＰＬＤ１０２へ供給し、ＰＬＤ１０２にＢＥ支援処理部２２２を構成させる。

ＢＥ−ＣＰＵ１０３のＰＬＤ制御部２３５は、ＰＬＤ１０２の動作を制御し、例えば、ＦＥ−ＣＰＵ１０１の故障発生時に、ＰＬＤ１０２のＢＥ支援処理部２２２から、認知処理部２１１が算出した目標経路などの情報を取得することができる。

なお、ＦＥ−ＣＰＵ１０１の故障が検出されて、ＦＥ−ＣＰＵ１０１が処理系から切り離された状態では、ＢＥ−ＣＰＵ１０３の通信処理部２３２は、センサＥＣＵ１０９から取得したセンサ情報を、ＰＬＤ１０２の高度演算処理部２２１へ供給する。また、高度演算処理部２２１では、センサ情報に基づく認知および判断の処理が行われ、判断処理で算出された目標経路は、ＰＬＤ制御部２３５がＢＥ支援処理部２２２を介して取得して、操作処理部２３１に入力される。よって、ＦＥ−ＣＰＵ１０１の故障が検出された後では、操作処理部２３１は、高度演算処理部２２１が算出した目標経路に基づいて各アクチュエータの制御量を算出することになる。

次に、実施の形態１に係る制御装置１００の動作をフローチャートを用いて説明する。図２および図３はＢＥ−ＣＰＵ１０３の動作を示すフローチャートであり、図２はＢＥ−ＣＰＵ１０３の定常動作（ＢＥ定常動作）を示しており、図３はＦＥ−ＣＰＵ１０１の故障が検出された後のＢＥ−ＣＰＵ１０３の動作（ＦＥ故障時ＢＥ動作）を示している。図４および図５はＦＥ−ＣＰＵ１０１の動作を示すフローチャートであり、図４はＦＥ−ＣＰＵ１０１の定常動作（ＦＥ定常動作）、図５はＦＥ−ＣＰＵ１０１の故障が検出された後の当該ＦＥ−ＣＰＵ１０１の動作（ＦＥ故障時動作）を示している。図６はＰＬＤ１０２の動作を示すフローチャートである。

図２および図３を参照して、ＢＥ−ＣＰＵ１０３の動作を説明する。制御装置１００が起動すると、ＢＥ−ＣＰＵ１０３は図２のＢＥ定常動作を開始する。

ステップＳ１０１では、通信処理部２３２が、センサＥＣＵ１０９からセンサ情報を取得する。ステップＳ１０２では、通信処理部２３２が、センサ情報をＦＥ−ＣＰＵ１０１およびＰＬＤ１０２へ供給する。ステップＳ１０３では、操作処理部２３１が、ＦＥ−ＣＰＵ１０１の処理結果（判断処理部２１２が算出した目標経路など）を取得する。

ステップＳ１０４では、ＦＥ故障判定部２３３が、ＦＥ−ＣＰＵ１０１の故障診断を行う。具体的には、ＦＥ故障判定部２３３は、まずＦＥ−ＣＰＵ１０１の処理結果に異常がないかを確認し、異常があればＦＥ−ＣＰＵ１０１の故障診断を行う。

故障診断によってＦＥ−ＣＰＵ１０１が正常と判断された場合（あるいはＦＥ−ＣＰＵ１０１の処理結果に異常が無い場合）、ステップＳ１０５へ進む。ステップＳ１０５では、操作処理部２３１が、ＦＥ−ＣＰＵ１０１の処理結果に基づいて、自車両を目標経路に従って走行させるためのアクチュエータの制御量を算出する。そしてステップＳ１０６では、通信処理部２３２が、操作処理部２３１により算出された制御量を示す制御情報をアクチュエータＥＣＵ１１０へ伝達する。ステップＳ１０６の後はステップＳ１０１へ戻る。

一方、ステップＳ１０４の故障診断によって、ＦＥ−ＣＰＵ１０１の故障が検出された場合には、図３のＦＥ故障時ＢＥ動作に進む。

ＦＥ故障時ＢＥ動作において、ステップＳ２０１では、ＦＥ故障判定部２３３が、ＦＥ−ＣＰＵ１０１に動作の停止を指示し、ＦＥ−ＣＰＵ１０１を処理系から切り離す。ステップＳ２０２では、ＰＬＤ更新処理部２３４が、ＰＬＤ１０２に、ＦＥ−ＣＰＵ１０１故障時用の処理ロジック（ＦＥ−ＣＰＵ１０１で実行されていた認知・判断処理の代替となる処理ロジック）を供給する。具体的には、ＰＬＤ更新処理部２３４は、ＲＯＭ１０５に記憶されているＢＥ支援処理モジュール２２２ｍをＰＬＤ１０２に供給する。ステップＳ２０３では、ＰＬＤ更新処理部２３４がＰＬＤ１０２の再構成を行い、ＰＬＤ１０２にＢＥ支援処理部２２２を構成させる。それにより、ＰＬＤ１０２は、ＦＥ−ＣＰＵ１０１故障時の動作モードに移行する。ＰＬＤ１０２がＦＥ−ＣＰＵ１０１故障時の動作モードになると、ＰＬＤ１０２の高度演算処理部２２１およびＢＥ支援処理部２２２が、ＦＥ−ＣＰＵ１０１の代わりに認知・判断処理を行う。

ステップＳ２０４では、通信処理部２３２が、センサＥＣＵ１０９からセンサ情報を取得する。ステップＳ２０５では、通信処理部２３２が、センサ情報をＰＬＤ１０２へ供給する。ステップＳ２０６では、操作処理部２３１が、ＰＬＤ１０２の処理結果（認知・判断処理で算出された目標経路など）を取得する。ステップＳ２０７では、操作処理部２３１が、自車両を目標経路に従って走行させるためのアクチュエータの制御量を算出する。ステップＳ２０８では、通信処理部２３２が、操作処理部２３１が算出した制御量を示す制御情報をアクチュエータＥＣＵ１１０へ伝達する。ステップＳ２０８の後はステップＳ２０４へと戻る。その後は、ステップＳ２０４〜Ｓ２０８の動作が繰り返される。

次に、図４および図５を参照して、ＦＥ−ＣＰＵ１０１の動作を説明する。制御装置１００が起動すると、ＦＥ−ＣＰＵ１０１は図４のＦＥ定常動作を開始する。

ステップＳ３０１では、ＦＥ−ＣＰＵ１０１が、ＢＥ−ＣＰＵ１０３の通信処理部２３２からセンサ情報を取得する。ステップＳ３０２では、ＦＥ−ＣＰＵ１０１が、ＰＬＤ１０２の高度演算処理部２２１を利用するために、センサ情報をＰＬＤ１０２へ供給する。ステップＳ３０３では、認知処理部２１１がＰＬＤ１０２の処理結果（認知・判断処理の一部の処理結果）を取得する。

ステップＳ３０４では、ステップＳ３０１で取得されたセンサ情報と、ステップＳ３０３で取得されたＰＬＤ１０２の処理結果とに基づいて、認知処理部２１１および判断処理部２１２が、認知・判断処理を実行する。ステップＳ３０５では、ＦＥ−ＣＰＵ１０１は、認知・判断処理の処理結果（自車両の目標経路など）をＢＥ−ＣＰＵ１０３へ伝達する。

このとき、ＦＥ−ＣＰＵ１０１の処理結果を取得したＢＥ−ＣＰＵ１０３により、その処理結果に異常がないか判定され、ＦＥ−ＣＰＵ１０１の故障診断が行われる（図２のステップＳ１０４）。ステップＳ３０６では、ＦＥ−ＣＰＵ１０１が、ＢＥ−ＣＰＵ１０３へ伝達した処理結果の正常／異常の判定結果を、ＢＥ−ＣＰＵ１０３から取得して確認する。

ＢＥ−ＣＰＵ１０３へ伝達した処理結果が正常と判定されていれば、ステップＳ３０１へ戻る。ＢＥ−ＣＰＵ１０３へ伝達した処理結果が異常と判定されていれば、ステップＳ３０７へ進み、ＦＥ診断部２１３がＦＥ−ＣＰＵ１０１の自己診断を実行する。

そしてステップＳ３０８では、ＦＥ−ＣＰＵ１０１は自己診断の結果を確認する。自己診断によりＦＥ−ＣＰＵ１０１が正常と判定された場合、ＦＥ−ＣＰＵ１０１は正常に動作可能であることをＢＥ−ＣＰＵ１０３に伝達し、ステップＳ３０１へ戻る。一方、自己診断によりＦＥ−ＣＰＵ１０１が異常と判定された場合は、図５のＦＥ故障時動作に進む。

ＦＥ故障時動作において、ステップＳ４０１では、ＦＥ−ＣＰＵ１０１が出力を停止する。ステップＳ４０２では、ＦＥ−ＣＰＵ１０１が、故障状態を動作履歴として残すために動作ログを保存する。そしてステップＳ４０３で、ＦＥ−ＣＰＵ１０１が動作を停止する。

次に、図６を参照して、ＰＬＤ１０２の動作を説明する。なお、ＰＬＤ１０２は、通常の動作モード（ＦＥ−ＣＰＵ１０１正常時の動作モード）で起動し、ＰＬＤ１０２には高度演算処理部２２１が構成されているものとする。

ステップＳ５０１では、ＰＬＤ１０２は、ＢＥ−ＣＰＵ１０３が取得したセンサ情報を、ＦＥ−ＣＰＵ１０１またはＢＥ−ＣＰＵ１０３から取得する。ステップＳ５０２では、高度演算処理部２２１の処理ロジックでセンサ情報を処理する。これにより、ＦＥ−ＣＰＵ１０１で行われる認知・判断処理の一部が実行され、ＦＥ−ＣＰＵ１０１の処理負荷が軽減される。ステップＳ５０３では、ＰＬＤ１０２が、認知処理部２１１の処理結果をＦＥ−ＣＰＵ１０１へ出力する。

ステップＳ５０４では、ＰＬＤ１０２は、外部から動作モードの切り替え指示（処理ロジックの変更指示）を受けたか否かを確認する。動作モードの切り替え指示が無ければ、ステップＳ５０１へ戻り、ステップＳ５０１〜Ｓ５０３が繰り返される。動作モードの切り替え指示があれば、ステップＳ５０５へ進む。本実施の形態の制御装置１００では、ＦＥ−ＣＰＵ１０１の故障が検出されたときに、ＢＥ−ＣＰＵ１０３からＰＬＤ１０２へ、ＦＥ−ＣＰＵ１０１故障時の動作モードへの切り替え指示がなされる。

ステップＳ５０５では、ＰＬＤ１０２が、動作モードを切り替えるために、新たな処理ロジックを構成するための処理モジュールを取得する。本実施の形態では、ステップＳ５０５において、ＰＬＤ１０２は、ＦＥ−ＣＰＵ１０１のＰＬＤ更新処理部２３４から供給されるＢＥ支援処理モジュール２２２ｍを取得する。

ステップＳ５０６では、ＰＬＤ１０２が、処理ロジックを再構成する。本実施の形態では、ステップＳ５０６において、ＰＬＤ１０２にＢＥ支援処理部２２２が構成され、それにより、ＰＬＤ１０２は、ＦＥ−ＣＰＵ１０１故障時の動作モードに移行する。

ステップＳ５０６で処理ロジックが再構成されると、ステップＳ５０１へ戻る。ただし、ＰＬＤ１０２はＦＥ−ＣＰＵ１０１故障時の動作モードになっているため、以降の動作では、ステップＳ５０２において、高度演算処理部２２１およびＢＥ支援処理部２２２が、ＦＥ−ＣＰＵ１０１の代わりに認知・判断処理を行うことになる。

以上説明したように、実施の形態１に係る制御装置１００によれば、ＦＥ−ＣＰＵ１０１が故障により利用できない状態になると、ＦＥ−ＣＰＵ１０１が行っていた認知・判断処理の代替処理をＰＬＤ１０２に構成された処理ロジックで行い、ＢＥ−ＣＰＵ１０３とＰＬＤ１０２とが連携して動作することにより、自車両の走行制御を継続することができる。よって、高価な高性能ＣＰＵであるＦＥ−ＣＰＵ１０１を冗長化することなく、ＦＥ−ＣＰＵ１０１の故障時でも自車両の走行制御を継続することができる。

また、ＦＥ−ＣＰＵ１０１が正常に動作するときには、ＰＬＤ１０２の処理ロジックで、ＦＥ−ＣＰＵ１０１のソフトウェア処理を補助して、ＦＥ−ＣＰＵ１０１の処理負荷を軽減できる。つまり、ＰＬＤ１０２の処理ロジックが、ＦＥ−ＣＰＵ１０１のソフトウェア処理の一部を分担することで、システム全体の処理性能を向上させることができる。

［変形例１］
実施の形態１では、ＦＥ−ＣＰＵ１０１の故障が検出されたときに、ＦＥ−ＣＰＵ１０１で行っていた処理の代替となる機能をＰＬＤ１０２に処理ロジックとして再構成した。しかし、ＦＥ−ＣＰＵ１０１が正常に動作しているときにも、ＰＬＤ１０２にＢＥ支援処理部２２２を構成しておき、ＦＥ−ＣＰＵ１０１およびＢＥ−ＣＰＵ１０３の両方からＰＬＤ１０２の処理ロジックを定常的に使用してもよい。例えば、ＦＥ−ＣＰＵ１０１だけでなく、ＢＥ−ＣＰＵ１０３でもソフトウェアでの処理能力が不足する場合には、ＰＬＤ１０２に実装される処理ロジックを処理の補助として使用してもよい。

［変形例２］
実施の形態１では、ＦＥ−ＣＰＵ１０１は、ＢＥ−ＣＰＵ１０３の通信処理部２３２を介してセンサＥＣＵ１０９のセンサ情報を取得する構成とした。しかし、例えば、図７のようにＦＥ−ＣＰＵ１０１を通信ＩＦ１０６に接続させ、ＦＥ−ＣＰＵ１０１が通信ＩＦ１０６を用いてセンサＥＣＵ１０９から直接センサ情報を取得してもよい。

＜実施の形態２＞
実施の形態１の制御装置１００では、ＦＥ−ＣＰＵ１０１が故障した場合に、ＦＥ−ＣＰＵ１０１を処理系から切り離した後、ＦＥ−ＣＰＵ１０１の処理を停止させた。しかし、ＦＥ−ＣＰＵ１０１を再起動させると故障から復旧する場合もある。そこで、実施の形態２では、ＦＥ−ＣＰＵ１０１を処理系から切り離した後、ＦＥ−ＣＰＵ１０１を再起動させ、正常に動作できる状態になれば、ＦＥ−ＣＰＵ１０１を処理系に復帰させてシステムを再構成する。なお、実施の形態２に係る制御装置１００の構成は、実施の形態１（図１）と同様である。

図８は、実施の形態２の制御装置１００において、ＦＥ−ＣＰＵ１０１の故障が検出された後のＢＥ−ＣＰＵ１０３の動作（ＦＥ故障時ＢＥ動作）を示すフローチャートである。図８のフローは、図３のフローに対し、ステップＳ２０８の後に、後述するステップＳ６０１〜Ｓ６０４を追加したものである。なお、ＢＥ−ＣＰＵ１０３の定常動作（ＢＥ定常動作）は、図２と同様である。

図２のＢＥ定常動作のステップＳ１０４において、ＦＥ−ＣＰＵ１０１が故障していると判定されると、ＢＥ−ＣＰＵ１０３は、図８のＦＥ故障時ＢＥ動作へ進む。ＦＥ故障時ＢＥ動作では、実施の形態１と同様にステップＳ２０１〜Ｓ２０８までの処理が行われ、その後、ステップＳ６０１において、ＦＥ故障判定部２３３が、ＦＥ−ＣＰＵ１０１が利用可能な状態かどうか（ＦＥ−ＣＰＵ１０１が故障から復旧しているかどうか）判定する。

ステップＳ６０１でＦＥ−ＣＰＵ１０１が利用不可と判断された場合は、ステップＳ２０４に戻り、ステップＳ２０４〜Ｓ２０８の動作が繰り返される。つまり、ＢＥ−ＣＰＵ１０３はＦＥ故障時ＢＥ動作を継続する。

一方、ステップＳ６０１でＦＥ−ＣＰＵ１０１が利用可能と判断された場合は、ステップＳ６０２へ進む。ステップＳ６０２では、ＰＬＤ更新処理部２３４が、ＰＬＤ１０２に、ＦＥ−ＣＰＵ１０１正常時用の処理ロジック（ＦＥ−ＣＰＵ１０１での認知・判断処理を補助する処理ロジック）を供給する。具体的には、ＰＬＤ更新処理部２３４は、ＲＯＭ１０５に記憶されている高度演算処理モジュール２２１ｍをＰＬＤ１０２に供給する。そしてステップＳ６０３では、ＰＬＤ更新処理部２３４がＰＬＤ１０２の再構成を行い、ＰＬＤ１０２に高度演算処理部２２１を構成させる。それにより、ＰＬＤ１０２は、通常の動作モードに移行する。その後、ステップＳ６０４において、ＦＥ故障判定部２３３がＦＥ−ＣＰＵ１０１へ動作復帰を指示し、図２のステップＳ１０１へ戻る。つまり、ＢＥ−ＣＰＵ１０３は、ＦＥ故障時ＢＥ動作からＢＥ定常動作へ復帰する。

図９は、実施の形態２の制御装置１００において、ＦＥ−ＣＰＵ１０１の故障が検出された後の当該ＦＥ−ＣＰＵ１０１の動作（ＦＥ故障時動作）を示すフローチャートである。図９のフローは、図５のフローに対し、ステップＳ４０３に代えて、後述するステップＳ７０１〜Ｓ７０７を追加したものである。なお、ＦＥ−ＣＰＵ１０１の定常動作（ＦＥ定常動作）は、図４と同様である。

図４のＦＥ定常動作のステップＳ３０７において、ＦＥ−ＣＰＵ１０１の故障が故障していると判定されると、ＦＥ−ＣＰＵ１０１は、図９のＦＥ故障時動作へ進む。ＦＥ故障時動作では、ＦＥ−ＣＰＵ１０１は、実施の形態１と同様にステップＳ４０１で出力を停止し、ステップＳ４０２で動作ログを保存した後、ステップＳ７０１において、故障を復旧させるために再起動する。ＦＥ−ＣＰＵ１０１が再起動すると、ステップＳ７０２へ進み、ＦＥ診断部２１３が、ＦＥ−ＣＰＵ１０１の自己診断を実行する。

ステップＳ７０３では、ＦＥ−ＣＰＵ１０１は自己診断の結果を確認する。自己診断によりＦＥ−ＣＰＵ１０１が異常と判定された場合、ステップＳ７０４へ進み、ＦＥ−ＣＰＵ１０１は動作を停止する。

一方、自己診断によりＦＥ−ＣＰＵ１０１が正常と判定された場合は、ステップＳ７０５へ進み、ＦＥ−ＣＰＵ１０１は故障から復旧して正常に動作可能であることをＢＥ−ＣＰＵ１０３に通知する。その後、ＦＥ−ＣＰＵ１０１は、ＢＥ−ＣＰＵ１０３から動作復帰の指示が届くのを待ち、ステップＳ７０６で動作復帰の指示を受信すると、ステップＳ７０７でＦＥ正常動作へ移行して、図４のステップＳ３０１へ戻る。つまり、ＦＥ−ＣＰＵ１０１は、ＦＥ故障時動作からＦＥ正常動作へ復帰する。

実施の形態２に係る制御装置１００によれば、実施の形態１と同様の効果が得られる他、ＦＥ−ＣＰＵ１０１が故障して認知・判断処理がＰＬＤ１０２で行われるようになった後でも、ＦＥ−ＣＰＵ１０１が故障から復旧すれば、ＦＥ−ＣＰＵ１０１による認知・判断処理を再開することができるという効果が得られる。

なお、実施の形態１で示した変形例１および変形例２は、実施の形態２の制御装置１００に対しても適用可能である。

＜実施の形態３＞
図１０は、実施の形態３に係る制御装置１００の構成を示すブロック図である。図１０の制御装置１００の構成は、図１の構成に対し、制御装置１００にセンサデバイス１１１を接続させ、ＰＬＤ１０２の処理ロジックとしてセンサ情報処理部２２３を追加したものである。また、ＲＯＭ１０５には、センサ情報処理部２２３の処理モジュールであるセンサ情報処理モジュール２２３ｍも記憶されている。

センサデバイス１１１は、自車両の物体を検出する制御装置１００専用のセンサである。本実施の形態では、センサデバイス１１１として、出力データ量が多く、当該データの処理に大きな演算負荷がかかるものを想定している。そのようなセンサデバイス１１１としては、カメラデバイスやＬＩＤＡＲ（Light Detection and Ranging、Laser Imaging Detection and Ranging）などが考えられる。

ＰＬＤ１０２に構成されるセンサ情報処理部２２３は、センサデバイス１１１の出力データを処理して、認知・判断処理に用いられるセンサ情報を生成する。センサ情報処理部２２３が出力するセンサ情報は、ＦＥ−ＣＰＵ１０１の認知処理部２１１および判断処理部２１２で行われる認知・判断処理に用いられる他、ＦＥ−ＣＰＵ１０１の故障時にＰＬＤ１０２の高度演算処理部２２１およびＢＥ支援処理部２２２で行われる認知・判断処理にも用いることができる。これにより、ＦＥ−ＣＰＵ１０１の処理負荷の増大を抑制しつつ、センサデバイス１１１の検知結果を用いた、精度の高い自動制御を行うことが可能となる。

実施の形態３に係る制御装置１００によれば、実施の形態１と同様の効果が得られる他、ＦＥ−ＣＰＵ１０１の処理負荷の増大を抑制しつつ、センサデバイス１１１の検知結果を用いた、精度の高い自動制御を行うことができるという効果が得られる。

なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略したりすることが可能である。

１００ 制御装置、１０１ ＦＥ−ＣＰＵ、１０２ ＰＬＤ、１０３ ＢＥ−ＣＰＵ、１０４ ＲＡＭ、１０５ ＲＯＭ、１０６ 通信ＩＦ、１０７ 内部バス、１０８ 車載ネットワーク、１０９ センサＥＣＵ、１１０ アクチュエータＥＣＵ、１１１ センサデバイス、２１１ 認知処理部、２１２ 判断処理部、２１３ ＦＥ診断部、２２１ 高度演算処理部、２２２ ＢＥ支援処理部、２２３ センサ情報処理部、２３１ 操作処理部、２３２ 通信処理部、２３３ ＦＥ故障判定部、２３４ ＰＬＤ更新処理部、２３５ ＰＬＤ制御部、２１１ｍ 認知処理モジュール、２１２ｍ 判断処理モジュール、２１３ｍ ＦＥ診断モジュール、２２１ｍ 高度演算処理モジュール、２２２ｍ ＢＥ支援処理モジュール、２２３ｍ センサ情報処理モジュール。

Claims (5)

1. 車両周辺の物体を検知するためのセンサ情報を処理するフロントエンドＣＰＵ(101)と、
   前記フロントエンドＣＰＵ(101)による前記センサ情報の処理結果に基づいて、前記車両のアクチュエータの制御情報を生成するバックエンドＣＰＵ(103)と、
   処理ロジックを動的に変更可能なプログラマブルロジックデバイス(102)と、
   を備え、
   前記フロントエンドＣＰＵ(101)の故障が検出されると、前記プログラマブルロジックデバイス(102)に、前記フロントエンドＣＰＵ(101)の代わりに前記センサ情報を処理する処理ロジックが構成され、前記バックエンドＣＰＵ(103)は、前記プログラマブルロジックデバイス(102)による前記センサ情報の処理結果に基づいて、前記アクチュエータの前記制御情報を生成する、
   車両用制御装置。
2. 前記フロントエンドＣＰＵ(101)において前記センサ情報の処理負荷が増大すると、前記プログラマブルロジックデバイス(102)に、前記フロントエンドＣＰＵ(101)の処理を補助する処理ロジックが構成される、
   請求項１に記載の車両用制御装置。
3. 前記フロントエンドＣＰＵ(101)の故障が検出された後、前記フロントエンドＣＰＵ(101)を再起動させ、前記フロントエンドＣＰＵ(101)が復旧すると、前記フロントエンドＣＰＵ(101)の故障が検出される前の状態に復帰する、
   請求項１または請求項２に記載の車両用制御装置。
4. 前記プログラマブルロジックデバイス(102)に、前記車両周辺の物体を検知するセンサデバイス(111)の出力データから前記センサ情報を生成する処理ロジックが構成される、
   請求項１から請求項３のいずれか一項に記載の車両用制御装置。
5. フロントエンドＣＰＵ(101)、バックエンドＣＰＵ(103)およびプログラマブルロジックデバイス(102)を備える車両用制御装置における車両制御方法であって、
   前記フロントエンドＣＰＵ(101)が、車両周辺の物体を検知するためのセンサ情報を処理し、
   前記バックエンドＣＰＵ(103)が、前記フロントエンドＣＰＵ(101)による前記センサ情報の処理結果に基づいて、前記車両のアクチュエータの制御情報を生成し、
   前記フロントエンドＣＰＵ(101)の故障が検出されると、
   前記プログラマブルロジックデバイス(102)が、前記フロントエンドＣＰＵ(101)の代わりに前記センサ情報を処理する処理ロジックが構成し、
   前記バックエンドＣＰＵ(103)が、前記プログラマブルロジックデバイス(102)による前記センサ情報の処理結果に基づいて、前記アクチュエータの前記制御情報を生成する、
   車両制御方法。

Images