(57)【要約】【課題】特定のＥＣＵに依存することなくＥＣＵの故障に対応可能な電子制御システム及び機能代行方法を提供すること。【解決手段】第１の電子制御ユニット１と１以上の第２の電子制御ユニットＡ、Ｂがネットワーク２０を介して接続された電子制御システム１００において、第１の電子制御ユニットは、自己機能の故障を検出する故障検出手段３６と、故障した故障機能の代行を第２の電子制御ユニットに要求する代行要求手段３５と、を有し、第２の電子制御ユニットは、故障機能の代替が可能か否かを判定する判定手段４２と、代行が可能と判定した場合、前記故障機能を代行する代行手段４１、４３と、を有する、ことを特徴とする。【選択図】図１
2010285001.tif 000002
【特許請求の範囲】
【請求項１】
第１の電子制御ユニットと１以上の第２の電子制御ユニットがネットワークを介して接続された電子制御システムにおいて、
第１の電子制御ユニットは、
自己機能の故障を検出する故障検出手段と、
故障した故障機能の代行を第２の電子制御ユニットに要求する代行要求手段と、を有し、
第２の電子制御ユニットは、
前記故障機能の代替が可能か否かを判定する判定手段と、
代行が可能と判定した場合、前記故障機能を代行する代行手段と、を有する、
ことを特徴とする電子制御システム。
【請求項２】
第１の電子制御ユニットは、
自己機能を提供するマイコン、及び、マイコンと接続された周辺ＩＣを有し、
前記周辺ＩＣに実装された前記故障検出手段が、マイコンの動作を監視して故障を検出する、
ことを特徴とする請求項１記載の電子制御システム。
【請求項３】
第１の電子制御ユニットが作動している時間帯に、第２の電子制御ユニットは作動していない時間帯がある、
ことを特徴とする請求項１又は２記載の電子制御システム。
【請求項４】
前記代行要求手段は、第１の電子制御ユニットのメモリ又はレジスタに記憶された故障が検出されるまでの演算情報を、第２の電子制御ユニットに送信し、
前記代行手段は、前記演算情報を処理した処理結果を第１の電子制御ユニットに送信する、
ことを特徴とする請求項１〜３いずれか１項記載の電子制御システム。
【請求項５】
第１の電子制御ユニットは、
マイコンと周辺機器を接続する入出力インターフェイスと、
前記入出力インターフェイスを第２の電子制御ユニットが引き継ぐよう、前記入出力インターフェイスの接続先をマイコンから第２の電子制御ユニットに切り替える切り替え手段と、
を有することを特徴とする請求項１〜５いずれか１項記載の電子制御システム。
【請求項６】
前記故障検出手段は、自己機能の特定の演算回路の故障を検出し、
前記代行手段は、前記演算回路と同等の演算回路により前記故障機能を代行する、
ことを特徴とする請求項４記載の電子制御システム。
【請求項７】
前記判定手段は、
前記代行要求手段から通知された代行のために必要な複数の仕様毎に、満たすか否かを記述した情報を第１の電子制御ユニットに送信し、
第１の電子制御ユニットは、満たすか否かを記述した情報に基づき代行を依頼する第２の電子制御ユニットを決定する、
ことを特徴とする請求項１〜６いずれか１項記載の電子制御システム。
【請求項８】
代行のために必要な複数の仕様に、遅延時間情報が含まれる、
ことを特徴とする請求項７記載の電子制御システム。
【請求項９】
第１の電子制御ユニットの機能を、ネットワークを介して接続されたと１以上の第２の電子制御ユニットが代行する機能代行方法において、
第１の電子制御ユニットの故障検出手段が、自己機能の故障を検出するステップと、
代行要求手段が、故障した故障機能の代行を第２の電子制御ユニットに要求するステップと、を有し、
第２の電子制御ユニットの判定手段が、前記故障機能の代替が可能か否かを判定するステップと、
代行手段が、代行が可能と判定した場合、前記故障機能を代行するステップと、を有する、ことを特徴とする機能代行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載された電子制御ユニットのフェイルセーフに関し、特に、故障した電子制御ユニットの機能を他の電子制御ユニットが代行する電子制御システム及び機能代行方法に関する。
【背景技術】
【０００２】
車両の基本機能や車載装置の電子化が進行する反面、数多くの電子制御ユニットが搭載された結果、電子制御ユニットの故障に対応する必要が生じている。故障した電子制御ユニットを検出するため、特定のＥＣＵが他のＥＣＵを監視する技術が考えられている（例えば、特許文献１，２参照。）。特許文献１には、通信ＥＣＵがナビＥＣＵ等の故障を検出すると、そのデータを情報提供センタに送信し、情報提供センタが機能を代行する技術が開示されている。また、特許文献２には、マネージャＥＣＵに必要機能を簡易化した基本プログラムを用意しておき、エンジンＥＣＵ等の故障を検出すると、適切なＥＣＵに基本プログラムをダウンロードしてそのＥＣＵがエンジンＥＣＵの肩代わりをする技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−２９７４４６号公報
【特許文献２】特開２００２−２２１０７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１又は２に記載された技術のように、特定のＥＣＵが他のＥＣＵに処理を振り分ける場合、特定のＥＣＵに故障が生じた場合の対応が困難になるという問題がある。また、特許文献１のように情報処理系の処理であれば他のＥＣＵで可能な処理もあるが、制御系の電子制御ユニットが故障した場合、故障した電子制御ユニットが管理するセンサやアクチュエータの処理を他のＥＣＵが肩代わりすることは困難である。この点について、特許文献２では、センサ及びアクチュエータを車載ネットワークに直接接続することで、他のＥＣＵが制御系の処理を肩代わりすることを可能とするが、かかる構成では故障の有無に拘わらずバス負荷が増大してしまい、センサやアクチュエータにアクセスするタイミングを確保することが困難になる。
【０００５】
本発明は、上記課題に鑑み、特定のＥＣＵに依存することなくＥＣＵの故障に対応可能な電子制御システム及び機能代行方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
第１の電子制御ユニットと１以上の第２の電子制御ユニットがネットワークを介して接続された電子制御システムにおいて、第１の電子制御ユニットは、自己機能の故障を検出する故障検出手段と、故障した故障機能の代行を第２の電子制御ユニットに要求する代行要求手段と、を有し、第２の電子制御ユニットは、故障機能の代替が可能か否かを判定する判定手段と、代行が可能と判定した場合、前記故障機能を代行する代行手段と、を有する、ことを特徴とする。
【発明の効果】
【０００７】
特定のＥＣＵに依存することなくＥＣＵの故障に対応可能な電子制御システム及び機能代行方法を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】ＥＣＵ１とＥＣＵ＿Ａ、ＥＣＵ＿Ｂの作動時間の関係の一例を示す図である。
【図２】電子制御システムの概略構成図の一例である。
【図３】ＥＣＵ１とＥＣＵ＿Ａの機能ブロック図の一例である。
【図４】代行必要仕様テーブルの一例を示す図である。
【図５】ＥＣＵ＿ＡがＥＣＵ１の機能を代行するまでの手順を示すフローチャート図の一例である。
【図６】ＥＣＵ１とＥＣＵ＿Ａの機能ブロック図の一例である（実施例２）。
【図７】代行必要仕様テーブルの一例を示す図である（実施例２）。
【図８】ＥＣＵ＿ＡがＥＣＵ１の機能を代行するまでの手順を示すフローチャート図の一例である。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための形態について図面を参照しながら実施例を挙げて説明する。
【００１０】
本実施形態の電子制御システム１００は、ＥＣＵ（Electronic  Control  Unit）１に故障が生じると、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１の機能の一部又は全部を代行する。電子制御システム１００は、特定のＥＣＵでなくＥＣＵ１の故障した機能を提供できるＥＣＵ＿Ａ又はＥＣＵ＿Ｂが機能を代行する。こうすることで、特定のＥＣＵに余計なコストをかけることなく、ＥＣＵ１の故障に適切な対応が可能となる。
【００１１】
図１は、ＥＣＵ１とＥＣＵ＿Ａ、ＥＣＵ＿Ｂの作動時間の関係の一例を示す図である。図１の斜線部はそのＥＣＵが作動していることを意味する。図示するように、ＥＣＵ１とＥＣＵ＿Ａ、又は、ＥＣＵ１とＥＣＵ＿Ｂは、作動時間に対し相補の関係にある。すなわち、ＥＣＵ１が走行中に起動しているのに対し、ＥＣＵ＿Ａ及びＥＣＵ＿Ｂはほぼ走行中に停止している。ＥＣＵ１は例えば、エンジンＥＣＵ、パワトレＥＣＵ、ブレーキＥＣＵ、パワステＥＣＵ（ＥＰＳ：electric  power  Steering)等、車両の基本機能「走る、曲がる、止まる」に用いられるアクチュエータを電子的に制御するＥＣＵである。一方、ＥＣＵ＿Ａは、例えば、車両近くの電子キーを無線通信により検出してドアをアンロックする等、駐車中に必要な機能を提供する。また、ＥＣＵ＿Ｂは、例えば、車両が後退走行する際に、車両後方のカメラ画像に予想軌跡を重畳して表示する等、車庫入れ中に必要な機能を提供する(バックガイドモニタ機能)。
【００１２】
電子制御システム１００は、ＥＣＵ１とＥＣＵ＿Ａ、又は、ＥＣＵ１とＥＣＵ＿Ｂのこのような関係を利用して、走行中にＥＣＵ１が故障した場合、走行中に処理能力に余裕のあるＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１の機能の一部又は全部を代行する（以下、単に機能代行という）。なお、本実施形態では、走行中に停止しているＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１を機能代行するが、機能代行するＥＣＵは処理能力に余裕があればよく、停止している必要はない。
【００１３】
走行中にＥＣＵ１が故障すると、ＥＣＵ１がＥＣＵ＿Ａ及びＥＣＵ＿Ｂに機能代行を要求し、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂのうち、ＥＣＵ１の機能の代行に必要な能力を備えたＥＣＵがＥＣＵ１の機能を代行する。ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが、ＥＣＵ１の機能代行が可能か否かを判定するので、特定のＥＣＵに依存することなく適切なＥＣＵが機能代行することができる。
【００１４】
ところで、ＥＣＵ１の故障には大きく次の２つの場合がある。
（Ｉ）ＥＣＵ１のＣＰＵの主要部が故障した場合
この場合、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが、ＥＣＵ１の機能を提供するために少なくとも最小限必要な機能を代行し、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１のＩ／Ｏ処理を引き継ぐ。
（II）ＥＣＵ１のＣＰＵの一部の機能が故障した場合
この場合、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ1の一部の機能のみを代行し、処理結果をＥＣＵ１に返す。ＥＣＵ１は故障する前と同様にＩ／Ｏ処理を実行する。
【実施例１】
【００１５】
本実施例では、（Ｉ）ＥＣＵ１のＣＰＵの主要部が故障した場合について説明する。
図２は、電子制御システム１００の概略構成図の一例を示す。ＥＣＵ１、ＥＣＵ＿Ａ及びＥＣＵ＿Ｂが車載ＬＡＮ２０を介して接続されている。ＥＣＵ＿Ｂの構成はＥＣＵ＿Ａと同様であるので省略した。マイコン１１には、バスを介して、周辺ＩＣ１２、メモリ１３、Ｉ／Ｏ１４，１５が接続され、更にＩ／Ｏ１４，１５にはセンサ１７とアクチュエータ１８が接続されている。マイコン１１は、後述するＣＰＵ３３、レジスタ１６、ＲＡＭ１９、ＣＡＮ通信部３１、スイッチ素子、ＡＳＩＣ（Application  Specific  Integrated  Circuit）等を有する。周辺ＩＣ１２は、リセット回路２７、タイマ、等を有する統合ＩＣである。メモリ１３は、例えばＥＥＰＲＯＭやフラッシュメモリ等の不揮発メモリであり、ＥＣＵ１が所定の機能を提供するためのアプリケーションプログラムやＯＳ（Ｏｐｅｒａｉｔｉｎｇ  Ｓｙｓｔｅｍ）等を記憶している。Ｉ／Ｏ１４はＡ／Ｄ変換回路、Ｉ／Ｏ１５はＤ／Ａ変換回路やモータ駆動回路、である。マイコン１１は、メモリ１３に記憶されたアプリケーションプログラムを読み出し、センサ１７が検出するセンサ信号に演算を施し、アクチュエータ１８を制御する等の処理を繰り返す。
【００１６】
なお、ＥＣＵ１がエンジンＥＣＵであれば、センサ１７は水温センサ、エンジン回転数センサ、Ｏ２センサ等であり、アクチュエータ１８はスロットルモータ、インジェクタ等である。また、ＥＣＵ１がブレーキＥＣＵであれば、センサ１７はマスタシリンダ圧センサ、車速センサ等であり、アクチュエータ１８は油圧回路に配置された増圧弁、減圧弁、圧力保持弁等である。また、ＥＣＵ１がトランスミッションＥＣＵであれば、センサ１７は油温センサ、アクセル開度センサ等であり、アクチュエータ１８はバルブボディに内蔵された各種のソレノイドである。
【００１７】
ＥＣＵ＿Ａのマイコン２１には、バスを介して、周辺ＩＣ２２、メモリ２３、Ｉ／Ｏ２４、２５が接続されている。Ｉ／Ｏ２４，２５にもセンサやアクチュエータが接続されていてもよい。マイコン２１は、ＣＰＵ４１、レジスタ２６、ＲＡＭ２９、ＣＡＮ通信部４３、スイッチ素子、ＡＳＩＣ等を有する。周辺ＩＣ２２は、リセット回路２７を有する。リセット回路２７は、マイコン２１をリセットすることで、マイコン２１を起動させる。ＥＣＵ＿Ｂも同様にリセット回路と判定回路を有し、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂのいずれかが、ＥＣＵ１の機能を代行するようになっている。
【００１８】
ＥＣＵ＿Ａがドアロック及びアンロックを制御するキーレスエントリーシステム用のＥＣＵ（照合ＥＣＵ又はボディＥＣＵ）の場合、Ｉ／Ｏ２４には電子キーの検知エリアを形成する通信装置やアンテナが接続され、Ｉ／Ｏ２５にはドアロックモータが接続されている。また、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが、バッグガイドモニタ機能を提供するＥＣＵの場合、Ｉ／Ｏ２４には後方を撮影するカメラが接続されている。
【００１９】
図３は、ＥＣＵ１とＥＣＵ＿Ａの機能ブロック図の一例である。ＥＣＵ１が故障を検出すると、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１のＩ／Ｏ１４、１５を引き継ぐ形で機能代行する。マイコン１１は、車載ＬＡＮ２０を介して他のＥＣＵと通信するためのＣＡＮ通信部３１、ＣＰＵ３３とＩ／Ｏ１４，１５、ＣＡＮ通信部３１とＩ／Ｏ１４，１５の接続を択一的に切り替えるＭＵＸ３４、及び、ＣＰＵ３３を介さずにＩ／Ｏ１４，１５とＣＡＮ通信部３１が相互にアクセスすることを可能にするＤＭＡＣ（Direct  Memory  Access  Controller）３２と有する。
【００２０】
また、ＥＣＵ＿Ａは、ＥＣＵ１の機能代行が可能か否かを判定する判定部４２を有する。ＥＣＵ＿Ｂも判定部を有するが図示を省略した。判定部４２は、例えば、起動したＥＣＵ＿ＡのＣＰＵ４１がメモリ２３に記憶されたプログラムを実行することで実現される。
【００２１】
〔故障の検出〕
まずＥＣＵ１の故障検出について説明する。ＣＰＵ３３の主要部が故障した場合、マイコン１１自体が故障を検出したり、故障後にＥＣＵ＿Ａ又はＥＣＵ＿Ｂに機能代行を要求するのは困難となる場合が多い。そこで、本実施例では、ＥＣＵ１の周辺ＩＣ１２が故障検出以降の処理を行う。
【００２２】
周辺ＩＣ１２は、ＥＣＵ１の機能代行をＥＣＵ＿Ａ又はＥＣＵ＿Ｂに要求する代行要求部３５、ＣＰＵ３３の故障を検出する故障検出部３６、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＩ／Ｏ１４、１５を引き継ぐことを可能にする切り替え部３７、を有する。これらの機能ブロックは、比較的単純な機能を提供するのでソフト又はハードのいずれで実装してもよい。
【００２３】
故障検出部３６は、例えばウォッチドッグタイマを実体とし、マイコン１１が定期的にウォッチドッグタイマに初期値をセットすることで、マイコン１１が正常動作していることを確認する。一方、マイコン１１が故障しウォッチドッグタイマに初期値をセットできなくなると、ウォッチドッグタイマの値がゼロになり周辺ＩＣ１２に割り込みする。故障検出部３６はこの割り込みからマイコン１１の異常を検出する。なお、ウォッチドッグタイマに書き込みが行われない故障では、所定のアプリケーションが応答待ちや無限ループに陥る場合が多く、不図示のリセット回路がＣＰＵ３３をリセットすることでＣＰＵ３３の機能が回復することがある。故障検出部３６は、何回かリセットしても再度ウォッチドッグタイマから割り込みが生じることからマイコン１１の故障を検出してもよい。
【００２４】
故障検出部３６がマイコン１１の故障を検出すると、代行要求部３５が機能代行をＥＣＵ＿Ａ又はＥＣＵ＿Ｂに要求する。ＣＰＵ３３の主要部が故障したことを想定すると、ＥＣＵ１のマイコン１１と同程度の処理能力を備えた、他のＥＣＵでないと機能代行が困難となる。また、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１と通信するまでの時間的な遅延があまり長いと、ＥＣＵ又はＥＣＵ＿ＢがＥＣＵ１のＩ／Ｏ１４，１５を引き継ぐことが困難である。また、ＥＣＵ１の制御に高い信頼性が要求される場合、機能代行するＥＣＵ＿Ａ又はＥＣＵ＿Ｂにも相応の信頼性が要求される。例えば、車両の操舵を制御するパワステＥＣＵのようにＥＣＵ１に要求される信頼性が高い場合、機能代行するＥＣＵ＿Ａ又はＥＣＵ＿Ｂも同等以上の信頼性を備えることが好ましい。
【００２５】
代行要求部３５は、代行要求する際、処理能力、遅延時間及び信頼性を含めた代行要求信号をＥＣＵ＿Ａ又はＥＣＵ＿Ｂに送信することで、機能代行を要求する。これにより、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂの判定部４２は、ＥＣＵ１の機能を代行できるか否かを判定できる。
【００２６】
代行要求部３５は、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂに機能代行を要求するため、必要な代行必要仕様を登録した代行必要仕様テーブル３８を記憶している。
図４は、代行必要仕様テーブル３８の一例を示す図である。処理能力には、代行先のＥＣＵが備える仕様として、ＣＰＵ３３の動作クロック周波数及び作業領域（ＲＡＭ２９）のメモリ容量、が登録されている。また、遅延時間及び信頼性が登録されている。遅延時間は、例えば、ＥＣＵ＿Ａ又はＥＣＵ＿ＢからＥＣＵ１に応答要求した場合の平均的な時間である。また、信頼性は、例えばＡ〜Ｃの３段階程度に定められており、代行必要仕様の信頼性がＡの場合、信頼性がＡのＥＣＵでなければ機能代行できないことを、信頼性がＢの場合、信頼性がＡ又はＢのＥＣＵでなければ機能代行できないことを、信頼性がＣの場合、信頼性がＡ〜ＣのＥＣＵでなければ機能代行できないことを、それぞれ意味する。代行必要仕様テーブル３８の代行必要仕様は、ＥＣＵ１の処理能力そのものを意味するとは限らず、ＥＣＵ１の機能のうち最小限、必要な機能を他のＥＣＵが代行するために必要な仕様であればよい。
【００２７】
代行要求部３５は、故障検出部３６が故障を検出すると、代行要求信号を、ＣＡＮ通信部３１を介してＥＣＵ＿Ａ又はＥＣＵ＿Ｂに送信する。ＣＡＮ通信部３１は、ＣＡＮプロトコルに従いフレームデータを生成し代行要求信号を格納する。ＣＡＮ通信部３１が同報的に代行要求信号を送信することで、車載ＬＡＮ２０に接続された全てのＥＣＵが、ＥＣＵ１の機能の代行が可能か否かを判定することができる。なお、予め定めた複数のＥＣＵ＿Ａ又はＥＣＵ＿Ｂにのみ代行要求信号を送信してもよい。
【００２８】
例えばＥＣＵ＿Ａ及びＥＣＵ＿Ｂが代行要求信号を受信して、代行可能であることを示す準備完了信号をＥＣＵ１に送信した場合、ＥＣＵ１はＥＣＵ＿Ａ又はＥＣＵ＿Ｂのいずれに代行を依頼するかを選択できることになる。準備完了信号については後述するが、ＥＣＵ１は準備完了信号を参照して最も好ましいＥＣＵ＿Ａ又はＥＣＵ＿Ｂを選択する。
【００２９】
また、代行必要仕様を全て満たすＥＣＵが複数存在する場合、ＥＣＵ１は、最も早く準備完了信号を送信したＥＣＵ＿Ａ又はＥＣＵ＿Ｂに、機能代行を依頼するものとする。こうすることで、ＥＣＵ１の機能を代行するＥＣＵＡ又はＥＣＵＢを早期に決定することができる。ＥＣＵ１は、機能の代行を依頼しないことになったＥＣＵに対し、個別に、機能代行が不要になった旨の信号を送信する。機能代行が不要になった旨の信号を受信したＥＣＵは停止することで、消費電力の増大を抑制できる。以下の処理は、ＥＣＵ＿Ａが機能代行するものとして説明する。
【００３０】
〔機能代行〕
ＣＰＵ３３の主要部が故障した場合、故障までＥＣＵ１が実行していた処理をＥＣＵ＿Ａが代行することになる。ここで、ＥＣＵ＿Ａのメモリ２３にＥＣＵ１が実行するアプリケーションプログラムが記憶されていることは少ないので、ＥＣＵ１はアプリケーションプログラムをＥＣＵ＿Ａに送信する。そして、ＥＣＵ１は、ＥＣＵ＿Ａがアプリケーションプログラムを実行した処理結果を受信する。
【００３１】
このため、ＥＣＵ＿Ａから準備完了信号を受信すると、ＥＣＵ１の切り替え部３７は、メモリ１３に記憶されたアプリケーションプログラムを送信するようＤＭＡＣ３２に要求する。ＥＣＵ＿Ａが充分なメモリ２３の空き容量を有すれば、ＤＭＡＣ３２はアプリケーションプログラムの全てをＥＣＵ＿Ａが機能代行を開始する前に送信できる。ＥＣＵ＿Ａが充分なメモリ２３の容量を有していない場合、所定量毎のアプリケーションプログラムをＥＣＵ＿Ａに送信することを繰り返す。本実施例では後者を例に説明する。
【００３２】
ところで、マイコン１１がアプリケーションプログラムの実行の途中で故障した場合、故障までの処理結果をＥＣＵ＿Ａが取得することで、故障までの制御との整合性を保ちやすくなる。例えば、モータ制御の一連のプロセスでは、それまでの処理結果を利用して次の制御量を決定することが多い。例えば、電気モータのトルクや回転数は、急激に増大させると乗員に違和感を感じさせるので、電気モータの通電量をフィードバック制御により決定する処理では、前回の制御量に応じた目標値が得られるように電気モータの制御量が決定されている。また、このように故障までの制御の整合性を保つ必要がなくても、故障までの処理結果を利用することで、ＥＣＵ＿Ａは早期にＥＣＵ１の機能代行を開始できる。アプリケーションプログラムによる故障までの演算情報は、主記憶装置であるＲＡＭ１９やＣＰＵ３３が使用するレジスタ１６に記憶されている。また、レジスタ１６にはＰＣ（プログラムカウンタ）等、ＥＣＵ１の状態を特定する情報が含まれているので、ＥＣＵ＿Ａが再開するアプリケーションプログラムのアドレスも明らかになる。したがって、ＥＣＵ＿ＡがＲＡＭ１９やレジスタ１６の演算情報を利用することで、アプリケーションプログラムを途中から再開できる。
【００３３】
なお、ＣＰＵ３３の主要部が故障している場合、そもそもＲＡＭ１９やレジスタ１６の内容を読み出すことができないことも多いので、ＤＭＡＣ３２はＲＡＭ１９やレジスタ１６の内容を呼び出せる場合に限り、これらの内容を送信する。
【００３４】
そして、切り替え部３７は、Ｉ／Ｏ１４，１５の接続先をＣＰＵ３３からＣＡＮ通信部３１に切り替える。ＣＰＵ３３の主要部が故障してしまうと、ＣＰＵ３３がＩ／Ｏ１４、１５を直接、制御することは困難となる。このため、切り替え部３７は、準備完了信号を受信すると、Ｉ／Ｏ１４，１５の接続先をＣＰＵ３３からＣＡＮ通信部３１に切り替える制御信号をＭＵＸ３４に出力する。ＭＵＸ３４がＩ／Ｏ１４，１５の接続先を、ＣＰＵ３３からＣＡＮ通信部３１に切り替えることで、センサ１７が検出したセンサ信号を、ＣＰＵ３３を介することなくＣＡＮ通信部３１がＥＣＵ＿Ａに送信することができる。また、ＥＣＵ＿Ａの処理結果が、直接Ｉ／Ｏ１５に送信され、ＥＣＵ＿ＡがＩ／Ｏ１５を介してアクチュエータ１８を制御することができる。
【００３５】
このように、ＥＣＵ１は、アプリケーションプログラムの送信、センサ信号の送信、処理結果の受信、を繰り返すことで、ＥＣＵ＿ＡがＥＣＵ１のＩ／Ｏ１４、１５を引き継ぐことを可能にする。
【００３６】
〔機能代行可能か否かの判定〕
図１にて説明したように、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂは停止中、走行中等の車両状態に応じて起動するので、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが代行要求信号を受信する際、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂは周辺ＩＣ２２のみが、マイコン２１の起動が必要か否かを判定するために作動している状態である。
【００３７】
ＣＡＮ通信部４３は、代行要求信号を受信するとリセット回路２７にリセット信号を出力させる。リセット回路２７がリセット信号をマイコン２１に出力することで、ＣＰＵ４１が起動して、ＥＣＵ＿ＡがＥＣＵ１の機能を代行することが可能となる。具体的には、マイコン２１のＣＰＵ４１やレジスタ２６などの回路がリセット信号を受けて初期化される。これにより、ＣＰＵ４１には所定の割り込みが発生し、ＣＰＵ４１がスタートアップルーチンを開始する。スタートアップルーチンは、マイコン２１を初期設定した後、Ｍａｉｎ関数をＣＰＵ４１に実行させるが、ＣＰＵ４１は代行要求信号を受信したことをフラグ等で検出し、ＭＡＩＮ関数からサブルーチン等で実装される判定部４２を呼び出す。
【００３８】
判定部４２は、代行要求信号に基づきＥＣＵ１の機能を代行できるか否かを判定する。判定部４２はＥＣＵ＿Ａの処理能力及び信頼性をパラメータとして記憶している。判定部４２は記憶しているパラメータと、代行要求信号に含まれる処理能力及び信頼性を比較して、ＥＣＵ1の機能を代行できるか否かを判定する。
【００３９】
一方、ＥＣＵ＿Ａが機能代行してからＥＣＵ１が処理結果を受信するまでの遅延時間は、車載ＬＡＮ２０のバス負荷が大きく影響し、固定とは限らない。そこで、判定部４２は、代行要求信号を受信した際のバス負荷から、要求される遅延時間を満たすか否かを判定する。バス負荷は、例えば次式で算出できる。
バス負荷＝  ｛ビット数×伝送時間｝／観測時間
観測時間は５〜１０秒程度で、ビット数は観測時間の間に車載ＬＡＮ２０上を伝送されるフレームデータの全てのビット数である。伝送時間は、１ビットの送信に必要な時間であり、例えば、伝送能力が５００ｋｂｐｓの場合、伝送時間は２マイクロ秒である。したがって、ＣＡＮ通信部３１が観測時間の間、車載ＬＡＮ２０上を伝送されるフレームデータを監視することで、バス負荷を求めることができる。判定部４２は、バス負荷と遅延時間の関係を定めたテーブルから予想される平均的な遅延時間を求め、代行要求信号に含まれる遅延時間と比較する。
【００４０】
判定部４２は判定結果を含む準備完了信号をＥＣＵ１に送信する。準備完了信号の態様はいくつか考えられる。
（ａ）処理能力、信頼性及び遅延時間について、それぞれ代行必要仕様を満たすか否かを判定し、全て満たす場合に、判定部４２が準備完了信号を送信する態様。
（ｂ）代行必要仕様の仕様毎に、満たすか否かを記述した情報を含む準備完了信号を送信する態様。
【００４１】
（ａ）の態様は、代行する可能性のある複数のＥＣＵ＿Ａ及びＥＣＵ＿Ｂが代行必要仕様を満たす可能性が高い場合に有効であり、（ｂ）の態様は、代行必要仕様を満たすＥＣＵを探すことが困難な場合に有効である。
【００４２】
例えば、処理能力と遅延時間は代行必要仕様を満たしていなくても許容できる場合がある。一方、信頼性が代行必要仕様を満たさない場合は代行しない方が好ましい。したがって、ＥＣＵ１の機能を代行するＥＣＵの選択に自由度を残しておくという意味では、（ｂ）の態様が好ましい。（ｂ）の準備完了信号を受信したＥＣＵ１の切り替え部３７は、代行必要仕様のうち、仕様の全てを満たすＥＣＵがなければ、優先度の高い仕様を満たすＥＣＵに機能の代行を依頼できる。ＥＣＵ１は、仕様毎にその優先度を予め定めている。
【００４３】
なお、判定部４２が、代行必要仕様の仕様を１つも満たしていないと判定した場合、準備完了信号をＥＣＵ１に送信しなくてよい。こうすることで、選択の対象を狭めることができる。
【００４４】
〔機能の代行中の警告〕
ＥＣＵ＿ＡがＥＣＵ１の機能を代行した場合、ＥＣＵ＿Ａは本来の機能であるドアのアンロック機能、又は、バッグガイドモニタ機能、を提供することが困難になる。したがって、機能代行したＥＣＵ＿Ａは、本来の機能が使用できない旨を運転者に通知することで、運転者が車両を駐車させる際に所望の機能を使用できない理由を把握できる。例えば、ＥＣＵ＿Ａは「バッグガイドモニタ用のＥＣＵは、現在、○○ＥＣＵの機能を代行中なので利用できません。」等のメッセージや、警告ランプを点灯するようメータＥＣＵやナビＥＣＵに要求することができる。なお、車両が駐車したり運転者が強制的に代行を終了させると、ＥＣＵ＿Ａは機能代行を終了し、本来の機能を提供する。
【００４５】
〔動作手順〕
図５は、ＥＣＵ＿ＡがＥＣＵ１の機能を代行するまでの手順を示すフローチャート図の一例である。図５のフローチャート図がスタートする際、ＥＣＵ１は起動中、ＥＣＵ＿Ａ及びＥＣＵ＿Ｂは周辺ＩＣ２２のみが起動した状態である。
【００４６】
まず、故障検出部３６がマイコン１１の故障を検出する（Ｓ１０）。これにより、代行要求部３５が代行必要仕様テーブル３８を参照し、代行要求信号をＥＣＵ＿Ａ及びＥＣＵ＿Ｂに送信する（Ｓ２０）。ＥＣＵ＿Ａ及びＥＣＵ＿Ｂのいずれも起動を開始するが、図５ではＥＣＵ＿Ａの手順のみを記載した。
【００４７】
ＥＣＵ＿Ａが起動すると（Ｓ３０）、判定部４２がＥＣＵ１の機能を代行できるか否かを判定する（Ｓ４０）。判定部４２は、予めパラメータとして記憶している処理能力と代行要求信号の処理能力を、予めパラメータとして記憶している信頼性と代行要求信号に含まれる信頼性とそれぞれ比較する。また、判定部４２は、算出したバス負荷に基づき予想される遅延時間を求め、機能代行信号に含まれる遅延時間と比較する。
【００４８】
判定部４２は、ＥＣＵ＿ＡがＥＣＵ１の機能を代行できると判定すると、準備完了信号をＥＣＵ１に送信する（Ｓ５０）。
【００４９】
切り替え部３７は、準備完了信号を送信したＥＣＵの中から代行必要仕様の全てを満たす例えばＥＣＵ＿Ａに、アプリケーションプログラム及びセンサ信号を送信する（Ｓ６０）。この場合、ＲＡＭ１９及びレジスタ１６の内容を共に送信することが好ましい。アプリケーションプログラム及びセンサ信号を送信するため、切り替え部３７は、メモリ１３に記憶されたアプリケーションプログラムを送信するようＤＭＡＣ３２に要求する。また、切り替え部３７は、Ｉ／Ｏ１４，１５の接続先をＣＰＵ３３からＣＡＮ通信部３１に切り替える制御信号をＭＵＸ３４に出力する。これにより、ＣＡＮ通信部３１はＥＣＵ＿Ａを宛先にセンサ信号を送信可能となる。
【００５０】
ＥＣＵ＿ＡのＣＡＮ通信部３１は、アプリケーションプログラムとセンサ信号を受信する。そして、ＥＣＵ＿ＡのＣＰＵ４１がアプリケーションプログラムを実行し、センサ信号に所定の演算を施すことでＥＣＵ１の機能を代行する（Ｓ７０）。ＥＣＵ＿ＡのＣＡＮ通信部３１は、処理結果をＥＣＵ１に送信する（Ｓ８０）。
【００５１】
ＥＣＵ１のＣＡＮ通信部３１は、受信した処理結果を、ＭＵＸ３４を介してＩ／Ｏ１５に送出する。これにより、ＥＣＵ＿ＡがＥＣＵ１のＩ／Ｏ１５を引き継ぐ態様でＥＣＵ１のアクチュエータ１８を制御することができる（Ｓ９０）。
【００５２】
ＥＣＵ＿Ａが引き継いだアクチュエータ１８の制御の後、ＥＣＵ１とＥＣＵ＿ＡはステップＳ６０〜Ｓ９０を繰り返す。
【００５３】
本実施例の電子制御システム１００によれば、故障したＥＣＵ１の機能を代行するための仕様を満たすＥＣＵ＿Ａを検出して、ＥＣＵ＿Ａが機能代行するので、特定のＥＣＵに依存することなくＥＣＵ１の故障に対し対応することができる。ＥＣＵ＿ＡはＥＣＵ１が起動している際、起動していないＥＣＵなので、機能を代行するＥＣＵ＿Ａの処理能力を増大する等、電子制御システム１００のトータルコストを増大させずにＥＣＵ１の故障に対応することができる。
【００５４】
なお、本実施例では、ＥＣＵ１の周辺ＩＣ１２が故障を検出したが、車載ＬＡＮ２０に接続された他のＥＣＵがＥＣＵ１の故障を検出することも可能である。故障を検出するＥＣＵは、起動中のＥＣＵであればよく、以下、ＥＣＵ＿Ｚという。ＥＣＵ＿Ｚは、例えば、ＥＣＵ１と通信不能になったことからマイコン１１の故障を検出する。ＥＣＵ＿Ｚはセンサ１７の検出したセンサ信号やＥＣＵ１が処理した処理結果を利用して、自らの処理を実行するＥＣＵであるため、ＥＣＵ＿Ｚは信号や処理結果が受信できないことから、ＥＣＵ１の故障を検出できる。
【００５５】
この場合、ＥＣＵ１は故障の検出によりＭＵＸ３４を自動的にＩ／Ｏ１４，１５側に切り替えておく。ＥＣＵ＿ＺはＥＣＵ１の故障を検出するとＥＣＵ＿Ａ及びＥＣＵ＿Ｂに機能代行を要求し、ＥＣＵ＿Ａ及びＥＣＵ＿Ｂが代行機能必要テーブルをＥＣＵ１から読み出すことで、機能代行可能であると判定したＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１の機能を代行する。以降は、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１のＣＡＮ通信部３１と通信を繰り返すことで、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ１の機能を代行できる。
【実施例２】
【００５６】
本実施例では、（II）ＥＣＵ１のＣＰＵ３３の一部の機能が故障した場合について説明する。この場合、ＥＣＵ＿Ａ又はＥＣＵ＿ＢがＥＣＵ1の一部の機能のみを代行し、処理結果をＥＣＵ１に返す。ＥＣＵ１は故障する前と同様にＩ／Ｏ処理を実行する。
【００５７】
図６は、ＥＣＵ１とＥＣＵ＿Ａの機能ブロック図の一例である。図６において図３と同一部には同一の符号を付しその説明は省略する。本実施例ではＣＰＵ３３の一部が故障したので、マイコン１１が故障の検出、機能代行の要求等を実行する。ＣＰＵ３３は、メモリ１３に記憶された故障用プログラムを実行することで実現される、故障検出部３６、代行要求部３５、演算完了部３９、及び、演算情報送信部４０を有する。ＣＰＵ３３が実行するアプリケーションプログラムは、定期的に故障用プログラムを呼び出す、又は、処理負荷が所定値以下になると故障用プログラムを呼び出す等により、ＣＰＵ３３が故障用プログラムを実行する。
【００５８】
〔ＥＣＵ１〕
故障検出部３６は、所定の演算の実行結果が予め記憶してある期待値と一致するか否かにより、マイコン１１の故障を検出する。所定の演算は、故障した回路を特定しやすいように、浮動小数点演算、乗算、除算、画像処理用演算、タイマ等、個別に用意されている。
【００５９】
代行要求部３５は、故障した回路に応じて、代行必要仕様を含む代行要求信号をＥＣＵ＿Ａ及びＥＣＵ＿Ｂに送信する。代行要求部３５は、実施例１と同様に代行必要仕様テーブル３８を有する。
図７は、代行必要仕様テーブル３８の一例を示す図である。故障した回路に対応づけて、代行必要仕様が登録されている。例えば、浮動小数点演算回路が故障した場合の代行必要仕様には、浮動小数点の演算精度が、画像処理回路が故障した場合の代行必要仕様には画像処理に必要なフレームレートが、それぞれ登録されている。代行要求部３５は、故障した回路に基づき代行必要テーブルを参照し、故障した回路と代行必要仕様を含む代行要求信号をＣＡＮ通信部３１から送信する。機能代行要求を受信したＥＣＵ＿Ａ又はＥＣＵ＿Ｂは、代行要求信号に基づき、自らが機能代行できるか否かを判定する。
【００６０】
演算情報送信部４０は、準備完了信号を受信すると、ＲＡＭ１９及びレジスタ１６に記憶された演算情報を、準備完了信号を送信したＥＣＵ＿Ａに送信する。ＲＡＭ１９及びレジスタ１６に記憶された演算情報は、ＥＣＵ１がアクチュエータ１８を制御するためにそれまで実行した演算の結果であるので、これをＥＣＵ＿Ａに送信することで、故障までの制御との整合性を保つことができる。
【００６１】
また、本実施例では、特定の回路による演算の代行をＥＣＵ＿Ａに要求するものなので、アプリケーションプログラムを送信しなくてもよいが、どのような演算を要求するかは、アプリケーションプログラムに記述された一部のプログラムコードを利用すればよい。すなわち、演算情報には最低限の演算内容が含まれる。機能代行するＥＣＵ＿Ａは、演算情報に基づき演算を代行し、処理結果をＥＣＵ１に送信する。
【００６２】
また、ＣＰＵ３３の一部が故障した場合、Ｉ／Ｏ１４からセンサ１７が検出したセンサ信号を用いて、故障前と同じ処理を実行するが、センサ信号はＲＡＭ１９又はレジスタ１６に記憶されている。このため、センサ信号は、ＣＰＵ３３がＲＡＭ１９又はレジスタ１６の内容をＥＣＵ＿Ａ又はＥＣＵ＿Ｂに送信した際に、演算情報と一緒に送信される。したがって、実質的にＥＣＵ１がＥＣＵ＿Ａに送信する情報は実施例１と同様である。
【００６３】
演算完了部３９は、処理結果を用いてアクチュエータ１８を制御するための演算を完了させる。すなわち、必要な一連の演算の途中で演算の代行をＥＣＵ＿Ａに要求した場合、ＥＣＵ＿Ａから受信した処理結果を用いて途中以降の演算を実行することで演算を完了させる。必要であれば、ＲＡＭ１９やレジスタ１６に記憶された演算情報を利用してもよい。
【００６４】
本実施例のようにＣＰＵ３３の例えば特定の回路だけが故障した場合、故障前と同様にＣＰＵ３３がＩ／Ｏ１４，１５を制御できる。したがって、演算完了部３９が演算を完了させた演算結果を用いてＣＰＵ３３がＩ／Ｏ１５からアクチュエータ１８を制御する。
【００６５】
なお、本実施例においても、ＥＣＵ＿ＡがＩ／Ｏ１５を引き継ぐことができる。例えば、ＥＣＵ１が送信する演算情報に、一連の演算の全ての手順を含めれば演算完了部３９が不要になる。また、一連の演算の最後で演算の代行をＥＣＵ＿Ａに要求した場合、演算完了部３９が演算実行する必要がない。したがって、このような場合は、ＥＣＵ＿Ａがアクチュエータ１８を制御することができる。すなわち、Ｉ／Ｏ１４の接続先をＣＰＵ３３に維持したまま、Ｉ／Ｏ１５の接続先をＣＡＮ通信部３１に切り替えれば、ＥＣＵ＿ＡがＩ／Ｏ１５を引き継ぐ態様となる。この場合、ＥＣＵ１が演算を完了させる必要がないので代行による制御の遅延を最小限にすることができる。
【００６６】
以上のように、本実施例の電子制御システム１００は、ＥＣＵ１が演算情報の送信、処理結果の受信、Ｉ／Ｏ１５の制御を繰り返すことで、ＥＣＵ＿Ａが故障したＥＣＵ１の機能を代行する。
【００６７】
〔ＥＣＵ＿Ａ又はＥＣＵ＿Ｂによる判定〕
ＥＣＵ＿Ａ又はＥＣＵ＿Ｂのブロック図は実施例１と同じである。すなわち、ＥＣＵ＿Ａが代行要求信号を受信すると、リセット回路がリセット信号をマイコン２１に出力することで、ＣＰＵ４１が起動する。ＣＰＵ４１は代行要求信号を受信したことをフラグ等で検出し、ＭＡＩＮ関数からサブルーチン等で実装される判定部４２を呼び出す。
【００６８】
判定部４２は、代行要求信号に含まれる故障した回路と代行必要仕様、に基づきＥＣＵ１の機能を代行できるか否かを判定する。ＥＣＵ＿ＡのＣＰＵ４１が有する回路と回路の仕様は固定であるので、図７と同様に判定部４２はＥＣＵ＿ＡのＣＰＵ４１が有する回路と仕様をパラメータとして記憶している。なお、遅延時間、信頼性に関する判定方法は実施例１と同じである。
【００６９】
判定部４２は、故障した回路の仕様、遅延時間、及び、信頼性が代行必要仕様を満たすか否かを判定し、全て満たす場合に、ＥＣＵ＿ＡがＥＣＵ１の機能を代行できると判定する。本実施例の場合、故障した回路の仕様を最低限満たす、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが準備完了信号をＥＣＵ１に送信することになる。ＥＣＵ１は、故障した回路の仕様を満たすＥＣＵ＿Ａ又はＥＣＵ＿Ｂから、最も好適なＥＣＵを機能代行の依頼先に決定できる。
【００７０】
判定部４２は、ＥＣＵ＿Ａが故障した回路の仕様を満たすと判定すると、準備完了信号をＥＣＵ１に送信する。ＥＣＵ＿Ａが故障した回路の仕様を満たさないと判定すると、判定部４２は、準備完了信号をＥＣＵ１に送信しない。この場合、他のＥＣＵ＿Ｂが準備完了信号を送信すれば、ＥＣＵ＿ＢがＥＣＵ１の機能を代行する。
【００７１】
〔動作手順〕
図８は、ＥＣＵ＿ＡがＥＣＵ１の機能を代行するまでの手順を示すフローチャート図の一例である。図８において、図５と同一部には同一の符号を付しその説明は省略する。本実施例では、ステップＳ６０において、ＥＣＵ１がＥＣＵ＿Ａに演算情報を送信する。なお、故障した回路以外の演算をＥＣＵ＿Ａに要求すれば、Ｉ／Ｏ１５の接続先をＣＰＵ３３からＣＡＮ通信部３１に切り替えることで、ＥＣＵ＿ＡがＩ／Ｏ１５を引き継ぐことができる。
【００７２】
また、ステップＳ９０において、演算完了部３９が処理結果を用いて演算を完了させると、演算結果をＩ／Ｏ１５を介してアクチュエータ１８に送出する。こうすることで、故障前と同様にＥＣＵ１がＩ／Ｏ１５を制御する態様でアクチュエータ１８を制御できる（Ｓ９０）。
【００７３】
本実施例の電子制御システム１００によれば、実施例１の効果に加え、ＥＣＵ１のＣＰＵ３３の一部の回路が故障した場合でも、ＥＣＵ＿Ａが機能代行することができる。
【実施例３】
【００７４】
実施例１と実施例２の機能代行の態様は、いずれか一方のみしか実装できないものではなく、両方を備えることが好ましい。実施例１と実施例２の機能代行の両方を備えることで、ＣＰＵ３３の主要部を故障した場合も一部の回路を故障した場合も、ＥＣＵ＿Ａ又はＥＣＵ＿Ｂが機能代行することができる。
【符号の説明】
【００７５】
１１、２１  マイコン
１２、２２  周辺ＩＣ
１３、２３  メモリ
１４、１５、２４，２５  Ｉ／Ｏ
１６、２６  レジスタ
１７        センサ
１８        アクチュエータ
１９、２９  ＲＡＭ
２０        車載LAN
２７        リセット回路
１００      電子制御システム
【図１】
2010285001.tif 000003
【図２】
2010285001.tif 000004
【図３】
2010285001.tif 000005
【図４】
2010285001.tif 000006
【図５】
2010285001.tif 000007
【図６】
2010285001.tif 000008
【図７】
2010285001.tif 000009
【図８】
2010285001.tif 000010