(57)【要約】【課題】コンピュータの処理負担をより軽減しながら、複数のハードウェアが単体及び組合せて故障した場合を適切に判定して、必要なフェイルセーフ動作を実行させること。【解決手段】車両に関する複数の故障項目単体での重み及び複数の故障項目が重複した場合の故障の重みを数値化したテーブルを記憶するＥＥＰＲＯＭ24と、複数の故障項目を検出するセンサ23，25ｂ，25ｄ，…と、検出結果に基づいてテーブルを参照し、故障項目単体での故障の重み及び故障項目が重複した場合の故障の重みの数値を抽出し、抽出した故障の重みの数値で所定の演算を実行して車両の故障レベルを判定し、判定結果に基づいて当該車両をフェイルセーフ動作させるＣＰＵ22とを備える。【選択図】図１
2016107836.tif 000002
【特許請求の範囲】
【請求項１】
車両に関する複数の故障項目単体での故障の重み及び複数の故障項目が重複した場合の故障の重みを数値化したテーブルを記憶する記憶部と、
前記複数の故障項目を検出する故障検出部と、
前記故障検出部での検出結果に基づいて前記記憶部のテーブルを参照し、前記故障項目単体での故障の重みとは別に複数の故障項目が同時に発生した際に前記故障項目が重複した場合の故障の重みの数値を抽出し、抽出した故障の重みの数値で所定の演算を実行する演算部と、
前記演算部で得た故障の重みの演算結果により車両の故障レベルを判定する判定部と、
前記判定部での前記故障レベルに応じた動作制限を前記車両に加える動作制御部と、
を備える車両。
【請求項２】
前記車両は、前記記憶部、故障検出部、演算部、判定部及び動作制御部を複数組備えて車両内ネットワークで接続してシステムを構成し、
前記複数組中の統括制御を行なう１組は、
前記記憶部が、故障項目が発生している組が単体である場合及び重複した場合のシステム故障レベルを数値化した統括テーブルをさらに記憶し、
前記演算部が、前記記憶部の統括テーブルを参照し、該当する故障レベルの数値を抽出し、抽出した故障レベルの数値で所定の演算を実行し、
前記判定部が、前記演算部で得た故障レベルの演算結果により車両の統括故障レベルを判定し、
前記動作制御部が、前記判定した統括故障レベルに応じた動作制限を前記車両に加える
請求項１記載の車両。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、電動車両に好適な車両に関する。
【背景技術】
【０００２】
従来、車両制御装置の構成要素が故障しているか否かの判定結果を基礎として、車両制御装置が全体として故障しているか否かを判定する故障判定ロジックを容易に再利用することを目的として、車両制御装置を構成するハードウェアのうち故障しているものの組合せに基づき、、車両制御装置の機能故障レベルを判定し、その機能故障レベルに応じたフェールセーフ機能を実施するようにした技術が提案されている。（例えば、特許文献１）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−１７９０１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前記特許文献に記載された技術は、予め故障するハードウェアの組合せを記憶しており、該当する故障の組合せが検出された場合には、その組合せ情報と一意に関連付けられている故障レベルを判定して、判定結果に応じたフェイルセーフ動作を実行するようにしたものである。
【０００５】
そのため、故障の検出対象となるハードウェアの組合せの数が増えるに連れて、判定に要する処理工程が長大なものとなり、コンピュータにより負担が大きくなるという不具合がある。
【０００６】
本願は前記のような実情に鑑みてなされたもので、その目的とするところは、コンピュータの処理負担をより軽減しながら、複数のハードウェアが単体及び組合せて故障した場合を適切に判定して、必要なフェイルセーフ動作を実行させることが可能な車両を提供することにある。
【課題を解決するための手段】
【０００７】
一実施形態の車両は、車両に関する複数の故障項目単体での故障の重み及び複数の故障項目が重複した場合の故障の重みを数値化したテーブルを記憶する記憶部と、前記複数の故障項目を検出する故障検出部と、前記故障検出部での検出結果に基づいて前記記憶部のテーブルを参照し、前記故障項目単体での故障の重みとは別に複数の故障項目が同時に発生した際に前記故障項目が重複した場合の故障の重みの数値を抽出し、抽出した故障の重みの数値で所定の演算を実行する演算部と、前記演算部で得た故障の重みの演算結果により車両の故障レベルを判定する判定部と、前記判定部での前記故障レベルに応じた動作制限を前記車両に加える動作制御部と、を備える。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る回路構成を示すブロック図。
【図２】同実施形態に係る車両制御に関する一連の処理内容を示すフローチャート。
【発明を実施するための形態】
【０００９】
以下、電動車両の車両制御装置に適用した場合の一実施形態について、図面を参照して説明する。  
図１は、車両制御装置の構成を示すブロック図である。車両制御装置は、バッテリ１１、高圧バッテリ１２、インバータ１３、検査ＥＣＵ１４、車両ＥＣＵ１５、レゾルバ１６、及びモータ１７を備える。
【００１０】
バッテリ１１は、２次電池で構成され、この電動車両全体の制御等の電源となる。このバッテリ１１の発する直流電力がインバータ１３内の電源回路２１に供給される。電源回路２１は、バッテリ１１からの直流電力を所定の電圧に変換して、このインバータ１３の動作制御を行なうＣＰＵ２２の電源部２２ａに供給する。
【００１１】
また、電源回路２１にはセンサ２３が設けられ、このセンサ２３がバッテリ１１から電源回路２１に供給される電圧と電流量を検出して、ＣＰＵ２２のＡ／Ｄ変換部（ＡＤＣ）２２ｂに送出する。
【００１２】
動作プログラムを記憶しているＣＰＵ２２は、シリアル入出力インタフェース（ＳＩＯ）２２ｃにより不揮発性メモリであるＥＥＰＲＯＭ２４と接続され、このＥＥＰＲＯＭ２４に記憶されている、後述するテーブル等を含む各種固定データを読出して、制御動作を実行する。  
なお、ＥＥＰＲＯＭ２４に記憶されているテーブル等を含む各種固定データは、そのデータ容量と、データの内容がインバータ毎の個体差に依存するものであるか否か等によって、ＣＰＵ２２が内蔵する不揮発性メモリ（不図示）に記憶されるものとしても良い。
【００１３】
前記検査ＥＣＵ１４は、当該車両を構成する多数のハードウェアを検査するためのコントロールユニットであり、ＣＰＵ２２のＣＡＮ部２２ｄと接続される。
【００１４】
前記車両ＥＣＵ１５は、当該車両を統括して制御するコントロールユニットであり、ＣＰＵ２２のＣＡＮ部２２ｅと接続される。前記ＣＡＮ部２２ｄ及びＣＡＮ部２２ｅは、いずれもＩＳＯ１１８９８及びＩＳＯ１１５１９に準拠したＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）規格に則った耐ノイズ性を考慮した入出力インタフェースである。
【００１５】
前記レゾルバ１６は、当該車両を駆動する前記モータ１７の回転角を検出するセンサであり、レゾルバ１６での検出結果はＣＰＵ２２のシリアル入出力インタフェース２２ｆに送出される。
【００１６】
モータ１７は、例えばＰＭＳＭ（永久磁石同期電動機）で構成され、当該車両の図示しない駆動軸と機械的に接続される。
【００１７】
前記高圧バッテリ１２は、複数の２次バッテリを接続して当該車両の駆動用電力を供給するものであり、この高圧バッテリ１２の発する直流電力が、インバータ１３内のＩＧＢＴ（絶縁ゲートバイポーラトランジスタ）回路２５にて交流電力に変換されて、前記モータ１７に供される。また、モータ１７で回生時に生じる交流電力がこのＩＧＢＴ回路２５で直流電力に変換されて、前記高圧バッテリ１２に充電される。
【００１８】
ＩＧＢＴ回路２５は、前記ＣＰＵ２２内のスイッチング制御部２２ｇによるオン／オフスイッチング動作により、高圧バッテリ１２の電力によるモータ１７の駆動と、モータ１７での回生電力による高圧バッテリ１２の充電とを切換える。
【００１９】
ＩＧＢＴ回路２５は、インバータ１３の主変換素子であるモジュール構造のＩＧＢＴ２５ａを備え、可変電圧可変周波数制御により前記モータ１７を駆動する。ＩＧＢＴ２５ａの動作状態はセンサ２５ｂにより検出され、前記ＣＰＵ２２の入出力インタフェース（ＩＯ）２２ｈに送出される。
【００２０】
加えて、このＩＧＢＴ回路２５での電流、電圧、及び温度の各情報２５ｃがセンサ２５ｄにより検出され、ＣＰＵ２２のＡ／Ｄ変換部（ＡＤＣ）２２ｉに送出される。
【００２１】
次に前記実施形態の動作について説明する。  
まず本実施形態の基本的な概念について説明する。  
本実施形態では、例えばＥＥＰＲＯＭ２４に記憶させたテーブルに基づく固定データと、センサ類からの検出結果に基づく異常発生フラグとを共に次の表のように行列形式で取扱うものとする。
【００２２】
【表１】
2016107836.tif 000003
【００２３】
ここで行列Ａが予め設定した複数の故障毎の重大性を点数化した固定データであり、ＩＥＣ（国際電気標準会議）規格によるＦＭＥＡ（故障モードとその影響の解析）等の国際規格に則って準備される。前記表１の行列Ａは４個の故障に対する４×４の行列を示したものであるが、実際の電動車両等においては１００個程度の異常項目に対する判定を行ない、それら異常の同時発生の組合せにも対応する。行列Ｂは動作状況に応じた異常発生フラグの変数を示す。具体的な数値を設定した例を次に示す。
【００２４】
【表２】
2016107836.tif 000004
【００２５】
行列Ａと行列Ｂを演算することで、異常が発生している項目に基づき、組合せも考慮した加点対象の点数を補抽出できる。同表２中の行列Ａにおいて、白地ではない淡い地色で示す数値が単独で発生した故障の重大性、濃い地色で示す数値が複数同時に発生した故障の重大性を示す。例えばここでは、「３」番目の故障と１番目の故障が同時発生した場合（ｘ[３][１]）の重大性増加分を「１０００」としている。
【００２６】
行列Ｂでは、白地ではない淡い地色で示すフラグが発生している故障（表では「２」番目と「３」番目）を示す一方で、白地で示す要素ｙ[３][２]の「１」が、後述するように、同時に故障していることを表している。実際には、ＣＰＵ２２が、例えば前記行列Ａ及び行列Ｂを用いて演算「Ｂ×Ａ×Ｂ」により複数の異常による重大性増加分を加味した結果を得るものとする。
【００２７】
【表３】
2016107836.tif 000005
【００２８】
ＣＰＵ２２は、こうして得られた重大性増加分を示す数値である「Ｂ×Ａ×Ｂ」の各要素の最大値「５０」から、故障のレベルを判定する。
【００２９】
次に本実施形態の具体的な動作について説明する。  
本実施形態においては、次に示す４段階の故障の判定レベルに対して、重大性を示す指標を点数化して与えるものとする。
【００３０】
【表４】
2016107836.tif 000006
【００３１】
図２は、前記ＣＰＵ２２は動作プログラムと、ＥＥＰＲＯＭ２４に記憶した前記テーブルに基づいて実行する、車両制御に関する一連の処理内容を示すフローチャートである。この処理は、当該電動車両の電源が投入されている状態では常時実行する。
【００３２】
その処理当初にＣＰＵ２２は、センサ類、すなわち前記センサ２３、ＩＧＢＴ回路２５のセンサ２５ｂ及びセンサ２５ｄ、及び前記レゾルバ１６の出力と、前記検査ＥＣＵ１４及び車両ＥＣＵ１５を介して送られてくる全センサの出力を取得する（ステップＳ０１）。
【００３３】
センサ出力を取得したＣＰＵ２２は、各センサ出力に対してそれぞれ予め設定されている閾値の範囲と比較することで、異常を生じているセンサ出力を判断する（ステップＳ０２）。
【００３４】
この判断結果に基づき、ＣＰＵ２２は例えばＥＥＰＲＯＭ２４から読出す重大性テーブルを参照して、異常と判断したセンサ出力に関連付けられている重大性を示す指標の点数を抽出する（ステップＳ０３）。ここでは説明を簡易化するために、各センサからの故障項目が８個であるものとすると、ＥＥＰＲＯＭ２４から読出す重大性テーブルは次のように構成される。
【００３５】
【表５】
2016107836.tif 000007
【００３６】
前記表５で示した重大性テーブルは、各故障に対して２つが同時に発生した場合の重大性増加分を設定している。これらのデータは、前述した如くＦＭＥＡ等の国際規格に則って準備される。  
なお前記表５中の故障Ａ，故障Ｂ，‥‥の具体的な例としては、ＩＧＢＴ回路２５内の各位置に設置した温度センサ２５ｄによりＩＧＢＴ２５が一定温度（例えば１２０℃）以上となった場合の「ＩＧＢＴ温度異常」、バッテリ１１からモータ１７の３相までの間に設置した電流センサ２５ｄにより電流が過剰（例えば５００Ａ以上）に流れた場合の「直流電流異常」、ＣＰＵ２２が上位の車両ＥＣＵ１５との間でチェックサム不一致などで一定時間以上（例えば規定受信間隔８（ミリ秒）の１００回分に相当する８００（ミリ秒））メッセージが受信できない場合の「ＣＡＮ通信異常」などが挙げられる。
同表５中、白地ではない淡い地色で示す数値が単独で発生した故障の重大性、濃い地色で示す数値が複数同時に発生した故障の重大性を示す。例えば、故障Ｅと故障Ｃが同時発生した場合の重大性増加分を「１０００」、故障Ｈと故障Ｅが同時発生した場合の重大性増加分を「１００」としている。
【００３７】
ここで前記テーブルの重大性枠を要素とする行列Ａを考える。
【００３８】
【表６】
2016107836.tif 000008
【００３９】
前記表６は、故障に対する重大性を行列形式で記述したもので、数学的な行列式を表すものではない。  
また同じ形式の行列Ｂを考えて、その要素に異常発生状態を示させるものとする。  
行列中の要素ｙ[ｉ][ｉ]は、ｉ番目の故障が発生している場合にフラグ「１」とし、発生していない場合にフラグ「０」とする。
【００４０】
前記表５の重大性テーブルにおける故障Ａからフラグ「１」を割り当てると、故障Ｃの発生はｙ[３][３]、故障Ｅの発生はｙ[５][５]となる。  
また、「ｉ＜ｊ」、且つ「ｉ≠ｊ」として２個の故障の同時発生フラグを  
ｙ[ｉ][ｊ]＝ｙ[ｉ][ｉ]＊ｙ[ｊ][ｊ]  
とすると、故障Ｃと故障Ｅの同時発生はｙ[３][５]となる。この異常発生状況のフラグをテーブル化する。
【００４１】
【表７】
2016107836.tif 000009
【００４２】
ここで前記の発生状態を示しているフラグを要素とする行列Ｂを考える。
【００４３】
【表８】
2016107836.tif 000010
【００４４】
前記行列Ａ及び行列Ｂと同じ形式の行列Ｃが、「Ｃ＝Ｂ×Ａ×Ｂ」であるとして、Ｃの要素を以下の通りとする。
【００４５】
【表９】
2016107836.tif 000011
【００４６】
故障Ｅと故障Ｃの２つが同時に発生している状態では、ｙ[ｉ][ｊ]は次の通りになる。すなわち、  
（ｙ[３][３]＝１、ｙ[５][５]＝１、それ以外のｙ[ｌ][ｍ]＝０）  
ｚ[５][３]＝ｘ[３][３]＋ｘ[５][３]＋ｘ[５][５]  
ＣＰＵ２２は、前記表８の重大性テーブルによりｘ[３][３]の点数「１００」、ｘ[５][３]の点数「１０００」、及びｘ[５][５]の点数「１０」を読出し、異常点数の演算  
ｚ[５][３]＝１００＋１０００＋１０  
＝１１１０  
を算出する。  
ここでＣＰＵ２２は、演算結果の点数が「１０」以上であるか否かにより、故障が発生しているか否かを判断する（ステップＳ０６）。  
前記演算結果の点数「１１１０」から、故障が発生していると判断した場合（ステップＳ０６のＹＥＳ）、ＣＰＵ２２は前記表１の指標に基づいて点数「１０００」を超えているために重故障と判断し、異常発生箇所と故障レベルとに応じて予め設定されているフェイルセーフ動作を実行した後（ステップＳ０９）、この図２の処理を一旦終了する。
【００４７】
また前記ステップＳ０６において、演算結果の点数が「１０」未満であり、故障が発生していないと判断した場合（ステップＳ０６のＮＯ）、ＣＰＵ２２は次に演算結果の点数が「１」以上であり、軽微な異常が発生しているか否かにより、ワーニングの必要があるか否かを判断する（ステップＳ０７）。
【００４８】
ここで演算結果の点数が「０」であり、軽微な異常も発生しておらず、ワーニングの必要はないと判断した場合（ステップＳ０７のＮＯ）、ＣＰＵ２２はそのままこの図２の処理を一旦終了する。
【００４９】
また前記ステップＳ０７において、演算結果の点数が「１」以上であり、軽微な異常が発生していると判断した場合（ステップＳ０７のＹＥＳ）、ＣＰＵ２２は異常発生箇所に応じて予め設定されているワーニング動作を実行した後（ステップＳ０８）、この図２の処理を一旦終了する。
【００５０】
なお前記説明では、同時に２箇所の故障が発生した場合について説明したが、同時に発生する故障の数がｍ（ｍ：３以上の自然数）である場合についても同様に重大性を点数化して演算することができる。
【００５１】
全体の故障項目数をｎ（ｎ＞ｍ）とした場合、  
ｘ[ｉ１][ｉ２]…[ｉｍ]  
（ｉ１からｉｍは、それぞれ１からｍまでの整数で、ｉ１＞ｉ２＞…＞ｉｍとする）  
ｍ個の故障１、…故障Ｍが同時に発生した場合の重大性増加分ｘは、  
ｘ[ｍ][ｍ−１]…[１]  
として与えられる。
【００５２】
組合せによる重大性ｚは、  
ｚ[ｍ][ｍ−１]…[１]＝ｘ[１][１]…[１]＋ｘ[２][２]…[２]  
＋ｘ[ｍ][ｍ]…[ｍ]＋ｘ[ｍ][ｍ−１]…[１]  
で与えられる。前記要素ｘ，ｚの個数は、それぞれｎのｍ乗個となる。
【００５３】
以下に、故障３個の組合せに対する解決策として、前記ｍ＝２の場合の手法を応用した簡易化手法について説明する。  
すなわち、故障項目数ｎ、組合せ数ｍとなるデータは個数が膨大となり、ＥＥＰＲＯＭ２４の記憶容量やＣＰＵ２２の処理負担も大きなものとなる一方で、ｍ＝３またはｍ＝４程度であれば、前述したｍ＝２の場合の重大性テーブルで簡易的に代用することが可能となる。
【００５４】
【表１０】
2016107836.tif 000012
【００５５】
同表１０中、淡いドットパターンで示す数値が単独で発生した故障の重大性、ハッチングで示す数値が複数同時に発生した故障の重大性を示す。例えば、故障Ｃと故障Ｄが同時発生した場合の重大性増加分を「４００」、故障Ｃと故障Ｅが同時発生した場合の重大性増加分を「４００」、故障Ｄと故障Ｅが同時発生した場合の重大性増加分を「４００」としている。
【００５６】
重大性増加分ｘは、故障Ｃと故障Ｄ、故障Ｃと故障Ｅ、故障Ｄと故障Ｅの同時発生に対して、  
ｘ[３][４]＝４００、  
ｘ[３][５]＝４００、  
ｘ[４][５]＝４００  
となる。本例では、３つの数値（４００）を加算して異常レベルの閾値（１０００）を超えるように設定する。前記表では、１０００／３≒３３３．３であるため、４００とした。
【００５７】
組合せ重大性ｚは、行列計算Ｃ＝Ｂ×Ａ×Ｂであり、  
異常発生フラグｙ[３][３]＝ｙ[４][３]＝ｙ[４][４]＝ｙ[５][３]＝ｙ[５][４]＝ｙ[５][５]＝１、それ以外のｙ[ｌ][ｍ]＝０となるので、前記表１０により  
ｚ[５][３]＝ｘ[３][３]＋ｘ[４][３]＋ｘ[４][４]＋ｘ[５][３]＋ｘ[５][４]＋ｘ[５][５]  
＝１００＋４００＋１００＋４００＋４００＋１０  
＝１４１０  
となり、重要性増加分ｚが「１４１０」となるため、前記表４での指標「１０００」を超える重故障であると判断する。  
前記故障Ｃ、故障Ｄ、及び故障Ｅのうちの２個が同時に発生した場合には、重要性増加分ｚがその閾値１０００を超えずに中故障と判断されることから、同時発生する故障の数に応じて重大性のレベルを任意に設定できる。
【００５８】
以上詳述した如く本実施形態によれば、ＣＰＵ２２の処理負担をより軽減しながら、複数のハードウェアが単体及び複数を組合せて故障した場合を適切に判定して、必要なフェイルセーフ動作を実行させることが可能となる。
【００５９】
その場合、重大性テーブルに設定する重大性増加値の数値の大小により、最終的に判断される重大性レベルをより上位、あるいは下位に変更することが可能となり、柔軟性に富んだ運用が可能となる。
【００６０】
加えて、同時に発生する故障の組合せやその個数等を変更する場合もテーブル値の再設定のみで実現可能であり、制御コードの追加や処理フローチャートの変更などの必要がないため、容易に仕様を変更できる。
【００６１】
なお前記実施形態では、主として車両駆動系の制御を行なうインバータ１３内のＣＰＵ２２による動作について説明したが、図１に示した如く、ＣＰＵ２２は検査ＥＣＵ１４及び車両ＥＣＵ１５とネットワーク接続されている。
【００６２】
したがって、主として駆動系の制御を行なうＣＰＵ２２に代わり、当該車両全体を統括制御する車両ＥＣＵ１５側で、車両の運転状況を総合的に判断することで、より最適なフェイルセーフ動作を実現させることができる。
【００６３】
その場合、車両ＥＣＵ１５に集約する各種センサの出力に関し、単に故障の有無を２値化した「０」「１」レベルの信号を送受して判断するのではなく、特に正常動作状態にない場合の機能故障レベルを多値化して記述した機能故障情報をそれぞれ出力するものとして、車両ＥＣＵ１５側では送られてきた機能故障情報で記述されている機能故障レベルに応じて当該車両をフェイルセーフ動作させるものとすれば、よりきめ細かく、より安全な動作を選択して実行させることができる。
【００６４】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６５】
１１…バッテリ、１２…高圧バッテリ、１３…インバータ、１４…検査ＥＣＵ、１５…車両ＥＣＵ、１６…レゾルバ、１７…モータ、２１…電源回路、２２…ＣＰＵ、２２ａ…電源部、２２ｂ…Ａ／Ｄ変換部（ＡＤＣ）、２２ｃ…シリアルインタフェース（ＳＩＯ）、２２ｄ…ＣＡＮ部、２２ｅ…ＣＡＮ部、２２ｆ…シリアル入出力インタフェース（ＳＩＯ）、２２ｇ…スイッチング制御部、２２ｈ…入出力インタフェース（ＩＯ）、２２ｉ…Ａ／Ｄ変換部（ＡＤＣ）、２３…センサ、２４…ＥＥＰＲＯＭ、２５…ＩＧＢＴ回路、２５ａ…ＩＧＢＴ、２５ｂ…センサ、２５ｃ…電圧・電流・温度情報、２５ｄ…センサ。
【図１】
2016107836.tif 000013
【図２】
2016107836.tif 000014