JP3883842B2

JP3883842B2 - 車両用電子制御装置

Info

Publication number: JP3883842B2
Application number: JP2001338210A
Authority: JP
Inventors: 啓晴竹内; 康弘田中
Original assignee: Denso Corp; Toyota Motor Corp
Current assignee: Denso Corp; Toyota Motor Corp
Priority date: 2001-11-02
Filing date: 2001-11-02
Publication date: 2007-02-21
Anticipated expiration: 2021-11-02
Also published as: US20030088358A1; US6990404B2; JP2003138981A

Description

【０００１】
【発明の属する技術分野】
本発明は、エンジン制御装置における監視ＣＰＵの制御ＣＰＵ異常検出方法に関するものである。
【０００２】
【従来の技術】
車載エンジンの制御を司る車両用電子制御装置（エンジンＥＣＵ）として、メイン及びサブの２つのＣＰＵを持つ構成が知られている。図８にその構成を示す。図８に示すエンジンＥＣＵ２０において、メインＣＰＵ２１は噴射制御及び点火制御を実施し、サブＣＰＵ２２は電子スロットル制御を実施する。メインＣＰＵ２１及びサブＣＰＵ２２では、ＵＡＲＴ等の通信方式を用いて相互のデータを送受信し、データを共有して協調制御を行っている。また、メインＣＰＵ２１は、サブＣＰＵ２２（スロットル制御）の監視制御として、サブＣＰＵ２２から出力されるウオッチドッグパルス（ＷＤパルス）をモニタし、ＷＤパルスの周期性からサブＣＰＵ２２の異常を検出する。サブＣＰＵ２２の異常時には、メインＣＰＵ２１がサブＣＰＵ２２にリセットをかけるようにしている。
【０００３】
また、サブＣＰＵ２２は、メインＣＰＵ２１で各種演算処理や通信処理等が正しく実施できているかどうを監視する。なお、ＷＤ回路２３は、メインＣＰＵ２１から出力されるＷＤパルスを入力し、該ＷＤパルスの周期性が崩れるとメインＣＰＵ２１にリセットをかける。
【０００４】
上記構成では、サブＣＰＵ２２において、メインＣＰＵ２１を監視するために異常判定値やパラメータしきい値等の監視用定数（監視用データ）を必要とする。この場合、比較的安価なマスクＲＯＭを使用して該マスクＲＯＭに監視用定数を格納しておき、サブＣＰＵ２２は必要に応じてマスクＲＯＭから監視用定数を読み出して使用することが考えられる。しかしながら、前記監視用定数は各車両毎に変更される可能性があり、定数変更の場合には、新たにマスクＲＯＭを設計し作製しなければならない。それ故、その度にマスク費用や定数変更等のソフト工数が発生する。
【０００５】
これを解決するために、ハード回路にて何通りかの監視用定数を設定しておき、それを選択的に使用するという方法が考えられる。具体的には、ハード回路にて複数異なるアナログ電圧を出力させ、それをサブＣＰＵ２２が選択的に入力する。しかしながら、この方法を用いる場合、監視用定数の組合せに限度があるために自由度が小さいことや、ハード回路やＡ／Ｄポート等が必要になりコストアップを招く等の問題が生ずる。
【０００６】
一方近年では、ＣＰＵの高機能・大容量化により、従来２つのＣＰＵを使用して実現してきたエンジン制御（噴射・点火制御）とスロットル制御とを１つの制御ＣＰＵで構成し、エンジンＥＣＵのコストダウンを図ることが考えられる。このような１ＣＰＵ構成のエンジンＥＣＵでは、スロットル制御の状態を監視するための監視ＣＰＵが別途必要になる。この場合、監視ＣＰＵは監視専用であるため低機能（安価）なものが採用される。そのため、上記の如く安価なマスクＲＯＭが使用され、各車両毎に監視用定数を変更する場合にマスク費用やソフト工数が発生する。
【０００７】
【発明が解決しようとする課題】
本発明は、上記問題に着目してなされたものであって、その目的とするところは、制御ＣＰＵの監視を正しく行い、しかもコスト的にも優れた車両用電子制御装置を提供することである。
【０００８】
【課題を解決するための手段】
請求項１に記載の発明では、制御ＣＰＵは各種の車両制御を実施する。監視ＣＰＵは、制御ＣＰＵを監視するための監視用データを制御ＣＰＵから受信してメモリに格納しており、この監視用データを用いて制御ＣＰＵの動作を監視する。この場合特に、監視ＣＰＵは、前記メモリ内の監視用データが正常かどうかを判定し、正常でない場合のみメモリ内の監視用データを更新する。本構成によれば、メモリ内に格納された監視用データは定期的に更新されるのではなく、データ異常時にのみ更新が許可される。故に、当該データが正常であり続ける限り、過去のデータがそのまま記憶保持される。場合によっては、本制御装置の初期出荷時の値がそのままメモリに残っていることも考えられる。
【０００９】
従って、その都度の制御ＣＰＵの監視に用いる監視用データは、正常な状態の制御ＣＰＵから送信されてきた可能性が高く、異常発生後の制御ＣＰＵから送信されてきた可能性が低いものとなる。故に、信頼性の高い監視用データを用い、制御ＣＰＵの監視を正しく行うことができる。しかも、車両毎に監視用データを予め設定しておく必要がないため、メモリの共通化が可能となり、コスト的にも優れたものとなる。
【００１０】
請求項２に記載の発明では、監視ＣＰＵは、制御ＣＰＵから受信した前記監視用データを一旦通信バッファに格納し、その後、前記メモリ内の監視用データが正常でない場合に通信バッファ内の監視用データをメモリにコピーする。この場合、例えば制御ＣＰＵが定期的に監視用データを送信してきたとしても、当該データは通信バッファに一時的に格納されるだけでメモリには必ずしも書き込まれない。従って、請求項１に記載した通り信頼性の高い監視用データを用い、制御ＣＰＵの監視を正しく行うことができるようになる。
【００１１】
請求項３に記載の発明では、制御ＣＰＵは、車両におけるエンジン制御機能並びに電子スロットル制御機能を有し、監視ＣＰＵは、前記監視用データを用いて制御ＣＰＵを監視する。この場合、コストダウンを図るべく制御機能を集約化した車両用電子制御装置において、制御ＣＰＵの監視を適正に行うことができる。
【００１２】
また、請求項４に記載の発明では、制御ＣＰＵは、車両におけるエンジン制御機能並びに電子スロットル制御機能に加え、異常発生時にエンジントルクを制御するための所定のフェイルセーフ機能を有し、監視ＣＰＵは、前記監視用データを用いて制御ＣＰＵでのフェイルセーフ実施状態を監視する。この場合、制御ＣＰＵでのフェイルセーフ実施状態を正しく監視することができる。
【００１３】
請求項５に記載の発明では、制御ＣＰＵは、電源投入に伴うイニシャル通信時には全ての監視用データを監視ＣＰＵに送信すると共に、定期的な通信では監視用データを分割して監視ＣＰＵに送信する。この場合、制御ＣＰＵから監視ＣＰＵへの定期的な通信データが少なくて済むため、通信負荷を減らすことができる。
【００１４】
請求項６に記載の発明では、監視ＣＰＵは、前記メモリ内の監視用データが正常でない場合、制御ＣＰＵに対してデータ送信要求を通知し、制御ＣＰＵはそのデータ送信要求を受けて監視用データを監視ＣＰＵに送信する。この場合、必要時にのみ制御ＣＰＵから監視ＣＰＵへ監視用データが送信されるため、通信負荷を減らすことができる。
【００１５】
請求項７，８に記載の発明は、イニシャル処理に際し、メモリに正しい監視用データが格納されなかった場合に関する発明である。すなわち、
・請求項７の発明では、イニシャル通信後に前記メモリ内に正しい監視用データが格納されていない場合、監視ＣＰＵがそれ以降全ての処理を中止する。
・請求項８の発明では、イニシャル通信後に前記メモリ内に正しい監視用データが格納されていない場合、監視ＣＰＵが制御ＣＰＵにリセットをかける。
【００１６】
請求項７，８の発明によれば、メモリ内に正しい監視用データが格納されてイニシャル処理が終了した場合にのみ、制御ＣＰＵの監視を含む各処理が実施される。従って、ＣＰＵ起動後において正しい監視用データにより適正に制御ＣＰＵを監視することができる。
【００１７】
また、請求項９に記載したように、前記メモリが電源遮断時にも記憶内容を保持する不揮発性のメモリであれば、メモリ内の監視用データを長期にわたって好適に記憶保持することが可能となる。実際には、前記メモリとしてバックアップ用電源が接続されたスタンバイＲＡＭやＥＥＰＲＯＭ等を用いれば良い。
【００１８】
請求項１０に記載の発明では、制御ＣＰＵから監視ＣＰＵへのデータ送信時には、制御ＣＰＵは監視用データと共に該データのデータチェック値（ミラーチェック値、サムチェック値等）を付してデータ送信を行うので、このデータチェック値によりデータ化けが検出できる。従って、メモリに格納する監視用データの信頼性がより一層高められる。
【００１９】
【発明の実施の形態】
（第１の実施の形態）
以下、この発明を具体化した第１の実施の形態を図面に従って説明する。
【００２０】
図１は、本実施の形態におけるエンジンＥＣＵの構成を示すブロック図である。図１において、エンジンＥＣＵ１０は、エンジンの噴射制御、点火制御及び電子スロットル制御を実施するための制御ＣＰＵ１１と、電子スロットル制御に関する監視制御を実施するための監視ＣＰＵ１２とを備える。制御ＣＰＵ１１は、エンジン回転数、吸気管内圧力、スロットル開度等々のエンジン運転情報を随時入力し、当該運転情報に基づき図示しないインジェクタ、イグナイタ、スロットルアクチュエータの駆動を制御する。また、制御ＣＰＵ１１は、監視ＣＰＵ１２の動作を監視するための監視制御を実施する。すなわち、監視ＣＰＵ１２は、制御ＣＰＵ１１に対して所定周期で反転するＷＤパルスを出力し、制御ＣＰＵ１１は、監視ＣＰＵ１２からのＷＤパルスが所定時間以上反転しなかった場合に監視ＣＰＵ１２に対してリセット信号を出力する。
【００２１】
制御ＣＰＵ１１及び監視ＣＰＵ１２には、それぞれバス等を介して通信バッファ１３，１４が接続されており、これら通信バッファ１３，１４間が通信ラインにより接続されている。
【００２２】
監視ＣＰＵ１２は、制御ＣＰＵ１１からの各種の受信データに基づいてスロットル制御が正しく実施されているかどうかを監視し、スロットル制御の異常を検出すると、制御ＣＰＵ１１に対してリセット信号を出力する。制御ＣＰＵ１１は、スロットル制御の異常発生時に所定のフェイルセーフ処理を実施する。フェイルセーフ処理として具体的には、エンジントルクを調整しつつ車両の退避走行（リンプホーム）を実現すべく、一部の気筒の燃料噴射を休止させる減筒制御や点火時期を遅角させる点火遅角制御等を実施する。
【００２３】
また、監視ＣＰＵ１２は、上記したスロットル制御監視に加え、フェイルセーフ処理の監視を実施する。すなわち、制御ＣＰＵ１１でのフェイルセーフ処理が正しく実施されているかどうかを監視する。
【００２４】
ここで、制御ＣＰＵ１１及び監視ＣＰＵ１２には各々にメモリ１５，１６が接続されており、このメモリ１５，１６には制御ＣＰＵ１１を監視するための定数データ（監視用データ）、より具体的にはスロットル制御監視或いはフェイルセーフ処理監視のための定数データが格納されている。この場合、監視ＣＰＵ１２は、制御ＣＰＵ１１側から定数データを取り込み、メモリ１６に格納する。そして、メモリ１６内の定数データを用いて制御ＣＰＵ１１の動作を監視する。
【００２５】
監視ＣＰＵ１２側のメモリ１６は、電源遮断時にも記憶内容を保持する不揮発性のメモリであるのが望ましく、実際には、メモリ１６としてバックアップ用電源が接続されたスタンバイＲＡＭやＥＥＰＲＯＭ等が用いられる。なお、他方のメモリ１５は、制御ＣＰＵ１１にＲＯＭとして実装される。
【００２６】
また、制御ＣＰＵ１１から監視ＣＰＵ１２へ定数データが送信される際、該定数データと共にミラーチェック値やサムチェック値が送信され、それらチェック値が通信バッファ１４に格納される。これにより、定数データの信頼性を高めている。
【００２７】
更に、制御ＣＰＵ１１は、ＷＤ回路１７に対して所定周期で反転するＷＤパルスを出力する。ＷＤ回路１７は、制御ＣＰＵ１１からのＷＤパルスが所定時間以上反転しなかった場合に制御ＣＰＵ１１に対してリセット信号を出力する。
【００２８】
次に、監視ＣＰＵ１２における定数データの更新手順について説明する。なおここで、制御ＣＰＵ１１は、電源投入に伴うイニシャル時の通信や定期的な通信（例えば４ｍｓｅｃ毎の通信）にて定数データを監視ＣＰＵ１２側に送信する。特に本実施の形態では、イニシャル通信時には全ての定数データを監視ＣＰＵ１２に送信すると共に、定期的な通信では定数データを分割して監視ＣＰＵ１２に送信する。監視ＣＰＵ１２側で受信した定数データはその都度通信バッファ１４に格納される。
【００２９】
図２は、監視ＣＰＵ１２のメモリチェック処理を示すフローチャートであり、本処理はイニシャル処理並びに１６ｍｓｅｃ処理として監視ＣＰＵ１２により実施される。
【００３０】
図２において、先ずステップ１０１では、メモリ１６に格納されている定数データをチェックする。このとき、ミラーチェックやサムチェック等を用い、定数データが破壊されていないかどうかを判定する。ステップ１０２では、定数データのチェック結果を判定する。チェック結果が正常である場合、そのまま本処理を終了する。また、チェック結果が異常である場合ステップ１０３に進み、メモリ１６に格納されている定数データを初期化する。続くステップ１０４では、データエラーフラグをＯＮする。
【００３１】
一方、図３は、定数格納処理を示すフローチャートであり、本処理は４ｍｓｅｃ処理として監視ＣＰＵ１２により実施される。
図３において、先ずステップ２０１では、データエラーフラグがＯＮであるか否かを判別し、同フラグ＝ＯＮであればステップ２０２に進む。ステップ２０２では、通信バッファ１４に格納されている定数データ（制御ＣＰＵ１１側から受信した定数データ）をチェックする。このとき、ミラーチェックやサムチェック等を用い、定数データが破壊されていないかどうかを判定する。ステップ２０３では、定数データのチェック結果を判定する。チェック結果が異常である場合、そのまま本処理を終了する。
【００３２】
また、チェック結果が正常である場合ステップ２０４に進み、定数データを通信バッファ１４からメモリ１６にコピーする。最後にステップ２０５では、データエラーフラグをＯＦＦする。要するに、通信バッファ１４内の定数データが正常な場合のみメモリ１６へのデータ格納が行われ、異常な場合にはデータ格納が行われることはない。なお、メモリ１６に未だ定数データを格納していない初期状態でも、前記図２の処理でデータエラーフラグがＯＮされ、それに伴い前記図３の処理でメモリ１６へのデータ格納が行われる。
【００３３】
ここで、図４はフェイルセーフ処理の監視手順を示すフローチャートであり、特に減筒制御に関する監視手順を示す。本処理は、監視ＣＰＵ１２により所定時間毎（例えば１６ｍｓｅｃ毎）に実施される。
【００３４】
図４において、ステップ３０１〜３０５では、各種の条件に基づいてフェイルセーフ処理の異常の有無を判別する。すなわち、
・今現在フェイルセーフ処理中（減筒制御中）であること、
・エンジン始動後、所定時間が経過していること、
・アクセルペダルが踏み込み操作されていないこと、
・エンジン回転数が所定回転以上であること、
・本来休止気筒である所定気筒が燃料噴射していること、
を全て満たす場合、フェイルセーフ処理が異常である旨判定する。この場合、ステップ３０６では異常カウンタを１インクリメントし、続くステップ３０７では、異常カウンタの値が所定回数よりも大きいか否かを判別する。そして、異常カウンタ＞所定回数の場合ステップ３０８に進み、制御ＣＰＵ１１をリセットする。
【００３５】
上記図４では、
・ステップ３０２での始動後経過時間の判定値、
・ステップ３０３でのアクセル開度判定値、
・ステップ３０４での異常回転数判定値、
・ステップ３０７での異常カウンタ判定値、
等が「定数データ」に該当する。
【００３６】
以上詳述した本実施の形態によれば、以下に示す効果が得られる。
メモリ１６内の定数データが正常でない場合のみ、監視ＣＰＵ１２が定数データを更新するので、メモリ１６内の定数データは、バッテリ初接続時など、制御ＣＰＵ１１が正常である時に送信されてきた可能性が高く、異常発生後の制御ＣＰＵ１１から送信されてきた可能性が低いものとなる。従って、信頼性の高い定数データを用い、制御ＣＰＵ１１の監視を正しく行うことができる。しかも、車両毎に定数データを予め設定しておく必要がないため、メモリ１６の共通化が可能となり、コスト的にも優れたものとなる。
【００３７】
コストダウンを図るべく制御機能を集約化したエンジンＥＣＵ１０において、制御ＣＰＵ１１の監視を適正に行うことができる。本実施の形態では特に、制御ＣＰＵ１１でのフェイルセーフ実施状態を正しく監視することができる。
【００３８】
制御ＣＰＵ１１は、イニシャル通信時には全ての定数データを監視ＣＰＵ１２側に送信すると共に、定期的な通信では定数データを分割して監視ＣＰＵ１２側に送信する。この場合、制御ＣＰＵ１１から監視ＣＰＵ１２への定期的な通信データが少なくて済むため、通信負荷を減らすことができる。
【００３９】
制御ＣＰＵ１１から監視ＣＰＵ１２へのデータ送信時には、制御ＣＰＵ１１は定数データと共に該データのデータチェック値を付してデータ送信を行うので、このデータチェック値によりデータ化けが検出できる。従って、メモリ１６に格納する定数データの信頼性が高められる。
【００４０】
（第２の実施の形態）
次に、本発明における第２の実施の形態について、上述した第１の実施の形態との相違点を中心に説明する。本実施の形態では、メモリ１６の定数データが正常でない場合に、監視ＣＰＵ１２が制御ＣＰＵ１１に対してデータ送信要求を通知し、制御ＣＰＵ１１はそのデータ送信要求を受けて定数データを監視ＣＰＵ１２側に送信する。
【００４１】
図５は、監視ＣＰＵ１２のメモリチェック処理を示すフローチャートであり、本処理はイニシャル処理並びに１６ｍｓｅｃ処理として監視ＣＰＵ１２により実施される。
【００４２】
図５において、ステップ４０１では、ミラーチェックやサムチェック等を用い、メモリ１６に格納されている定数データをチェックする。ステップ４０２では、定数データのチェック結果を判定する。チェック結果が正常である場合ステップ４０３に進み、定数転送要求フラグをＯＦＦする。これに対し、チェック結果が異常である場合ステップ４０４に進み、メモリ１６に格納されている定数データを初期化する。更にステップ４０５では、定数転送要求フラグをＯＮする。この定数転送要求フラグは、定期的な通信処理にて制御ＣＰＵ１１に対して通知される。
【００４３】
一方、図６は、制御ＣＰＵ１１における通信処理を示すフローチャートであり、本処理は例えば４ｍｓｅｃ毎に制御ＣＰＵ１１により実施される。
図６において、ステップ５０１では、通常時の送信データ（但し、定数データ以外のデータ）を通信バッファ１３にセットする。続くステップ５０２では、定数転送要求フラグがＯＮであるか否かを判別する。同フラグ＝ＯＮであればステップ５０３に進み、定数データ（監視用定数）も通信バッファ１３にセットする。その後、ステップ５０４では、通信処理を起動し、通信バッファ１３内のデータを監視ＣＰＵ１２側に送信する。
【００４４】
以上第２の実施の形態によれば、上記実施の形態と同様に、制御ＣＰＵ１１の監視を適正に行い、しかもコスト的にも優れたエンジンＥＣＵ１０が提供できる。また、定数転送要求フラグ（データ送信要求）に従い必要時にのみ制御ＣＰＵ１１から監視ＣＰＵ１２へ定数データが送信されるため、通信負荷を減らすことができる。
【００４５】
（第３の実施の形態）
本実施の形態では、電源投入に伴うイニシャル処理に際し、メモリ１６に正しい定数データが格納されなかった場合の特徴的な構成を説明する。図７は、監視ＣＰＵ１２により実施されるイニシャル処理を示すフローチャートである。
【００４６】
図７において、ステップ６０１では、イニシャル通信により定数データを通信バッファ１４に受信する。ステップ６０２では、ミラーチェックやサムチェック等を用い、メモリ１６に格納されている定数データをチェックする。ステップ６０３では、定数データのチェック結果を判定する。チェック結果が異常である場合に限りステップ６０４に進み、ミラーチェックやサムチェック等を用い、通信バッファ１４に格納されている定数データ（制御ＣＰＵ１１側から受信した定数データ）をチェックする。ステップ６０５では、定数データのチェック結果を判定する。チェック結果が正常である場合ステップ６０６に進み、定数データを通信バッファ１４からメモリ１６にコピーする。
【００４７】
また、チェック結果が異常である場合ステップ６０７に進み、それ以降の全ての処理を中止する。或いは、制御ＣＰＵ１１にリセットをかける。このステップ６０７の処理によれば、エンジンの運転が強制的に停止される。従って、制御ＣＰＵ１１の異常に伴うエンジントルクや回転数の変動が未然に防止できる。
【００４８】
以上第３の実施の形態によれば、既述の効果に加えて以下の効果が得られる。つまり、メモリ１６内に正しい定数データが格納されてイニシャル処理が終了した場合にのみ、制御ＣＰＵ１１の監視を含む各処理が実施される。従って、ＣＰＵ起動後において正しい定数データにより適正に制御ＣＰＵ１１を監視することができる。
【００４９】
なお、上記各実施の形態では、制御ＣＰＵ１１として、車両におけるエンジン制御機能と電子スロットル制御機能とを有するものを用いたが、この構成を変更する。例えば、エンジン制御用のＣＰＵ（メインＣＰＵ）と電子スロットル制御用のＣＰＵ（サブＣＰＵ）とを個別に設ける構成であっても良い（図８参照）。この場合、サブＣＰＵがフェイルセーフ監視の制御を実施する。また、サブＣＰＵはメモリ内の定数データが異常である場合にのみ定数データを更新する。この構成においても、信頼性の高い定数データを用い、メインＣＰＵの動作を適正に監視することができる。
【図面の簡単な説明】
【図１】発明の実施の形態におけるエンジンＥＣＵの概要を示す構成図。
【図２】監視ＣＰＵによるメモリチェック処理を示すフローチャート。
【図３】監視ＣＰＵによる定数格納処理を示すフローチャート。
【図４】監視ＣＰＵによるフェイルセーフ監視処理を示すフローチャート。
【図５】監視ＣＰＵによるメモリチェック処理を示すフローチャート。
【図６】制御ＣＰＵによる通信処理を示すフローチャート。
【図７】監視ＣＰＵによるイニシャル処理を示すフローチャート。
【図８】従来技術におけるエンジンＥＣＵの構成を示すブロック図。
【符号の説明】
１０…エンジンＥＣＵ、１１…制御ＣＰＵ、１２…監視ＣＰＵ、１４…通信バッファ、１６…メモリ。

Claims

各種の車両制御を実施する制御ＣＰＵと、該制御ＣＰＵに対して通信可能に接続され、制御ＣＰＵの動作を監視する監視ＣＰＵとを備え、監視ＣＰＵでは、制御ＣＰＵを監視するための監視用データを制御ＣＰＵから受信してメモリに格納する車両用電子制御装置において、
監視ＣＰＵは、前記メモリ内の監視用データが正常かどうかを判定し、正常でない場合のみメモリ内の監視用データを更新することを特徴とする車両用電子制御装置。
監視ＣＰＵは、制御ＣＰＵから受信した前記監視用データを一旦通信バッファに格納し、その後、前記メモリ内の監視用データが正常でない場合に通信バッファ内の監視用データをメモリにコピーする請求項１記載の車両用電子制御装置。
制御ＣＰＵは、車両におけるエンジン制御機能並びに電子スロットル制御機能を有し、監視ＣＰＵは、前記監視用データを用いて制御ＣＰＵを監視する請求項１又は２記載の車両用電子制御装置。
制御ＣＰＵは、車両におけるエンジン制御機能並びに電子スロットル制御機能に加え、異常発生時にエンジントルクを制御するための所定のフェイルセーフ機能を有し、監視ＣＰＵは、前記監視用データを用いて制御ＣＰＵでのフェイルセーフ実施状態を監視する請求項１又は２記載の車両用電子制御装置。
制御ＣＰＵは、電源投入に伴うイニシャル通信時には全ての監視用データを監視ＣＰＵに送信すると共に、定期的な通信では監視用データを分割して監視ＣＰＵに送信する請求項１乃至４の何れかに記載の車両用電子制御装置。
監視ＣＰＵは、前記メモリ内の監視用データが正常でない場合、制御ＣＰＵに対してデータ送信要求を通知し、制御ＣＰＵはそのデータ送信要求を受けて監視用データを監視ＣＰＵに送信する請求項１乃至４の何れかに記載の車両用電子制御装置。
監視ＣＰＵでは、電源投入に伴うイニシャル通信時に制御ＣＰＵから監視用データを受信し、そのイニシャル通信後に前記メモリ内に正しい監視用データが格納されていない場合、それ以降全ての処理を中止する請求項１乃至６の何れかに記載の車両用電子制御装置。
監視ＣＰＵでは、電源投入に伴うイニシャル通信時に制御ＣＰＵから監視用データを受信し、そのイニシャル通信後に前記メモリ内に正しい監視用データが格納されていない場合、制御ＣＰＵにリセットをかける請求項１乃至６の何れかに記載の車両用電子制御装置。
前記メモリは、電源遮断時にも記憶内容を保持する不揮発性のメモリである請求項１乃至８の何れかに記載の車両用電子制御装置。
制御ＣＰＵから監視ＣＰＵへのデータ送信時には、制御ＣＰＵは監視用データと共に該データのデータチェック値を付してデータ送信を行う請求項１乃至９の何れかに記載の車両用電子制御装置。