JP2003137045A

JP2003137045A - 車両用電子制御装置

Info

Publication number: JP2003137045A
Application number: JP2001334366A
Authority: JP
Inventors: Toshiaki Kobayashi; 稔昌小林; Hiroharu Takeuchi; 啓晴竹内
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2001-10-31
Filing date: 2001-10-31
Publication date: 2003-05-14
Anticipated expiration: 2021-10-31
Also published as: JP3901987B2

Abstract

(57)【要約】【課題】制御ＣＰＵと監視ＣＰＵとを備える車両用電子
制御装置において、制御ＣＰＵの通信異常を精度良く検
出すること。【解決手段】エンジンＥＣＵ１０は、各種の車両制御を
実施する制御ＣＰＵ１１と、該制御ＣＰＵ１１に対して
通信可能に接続され、制御ＣＰＵ１１の動作を監視する
監視ＣＰＵ１２とを備える。監視ＣＰＵ１２は受信割り
込み機能を持たず、制御ＣＰＵ１１からのデータ送信に
同期して制御ＣＰＵ１１へデータを返信する。制御ＣＰ
Ｕ１１は、監視ＣＰＵ１２へのデータ送信の都度、前回
送信時とは異なる通信監視用データを付してデータ送信
を行い、監視ＣＰＵ１２は、前記通信監視用データが更
新されているかどうかにより通信異常を判定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、各種の車両制御を
実施する制御ＣＰＵとこの制御ＣＰＵを監視する監視Ｃ
ＰＵとを備える車両用電子制御装置に関するものであ
る。

【０００２】

【従来の技術】車載エンジンの制御を司る車両用電子制
御装置（エンジンＥＣＵ）として、噴射制御及び点火制
御を実施するための噴射・点火制御用ＣＰＵと、電子ス
ロットル制御を実施するためのスロットル制御用ＣＰＵ
とからなる２つのＣＰＵを持つ構成が知られている。

【０００３】これに対し近年では、ＣＰＵの高機能・大
容量化により、従来２つのＣＰＵを使用して実現してき
たエンジン制御（噴射・点火制御）と電子スロットル制
御とを１つの制御ＣＰＵで構成し、エンジンＥＣＵのコ
ストダウンを図ることが考えられる。このような１ＣＰ
Ｕ構成のエンジンＥＣＵでは、電子スロットル制御の状
態を監視するための監視ＣＰＵが別途必要になる。この
場合、監視ＣＰＵは監視専用であり低機能（安価）なも
のが採用されるため、監視ＣＰＵとして制御ＣＰＵの通
信異常を精度良く検出できる構成が望まれている。特に
制御ＣＰＵ側が全ての主導権を持ち、監視ＣＰＵ側では
制御ＣＰＵからのデータ送信に同期してハード的にデー
タを返信する場合、監視ＣＰＵでは受信割り込み機能を
持たず、制御ＣＰＵの通信異常を検出することが困難と
なる。

【０００４】

【発明が解決しようとする課題】本発明は、上記問題に
着目してなされたものであって、制御ＣＰＵと監視ＣＰ
Ｕとを備える車両用電子制御装置において、制御ＣＰＵ
の通信異常を精度良く検出することができる構成を提供
することを目的とする。

【０００５】

【課題を解決するための手段】請求項１に記載の発明で
は、制御ＣＰＵは各種の車両制御を実施し、監視ＣＰＵ
は制御ＣＰＵの動作を監視する。また、制御ＣＰＵは、
監視ＣＰＵへのデータ送信の都度、前回送信時とは異な
る通信監視用データを付してデータ送信を行い、監視Ｃ
ＰＵは、前記通信監視用データが更新されているかどう
かにより通信異常を判定する。前記通信監視用データ
は、データ送信の都度更新されるカウンタ値であると良
い（請求項２）。例えば制御ＣＰＵから監視ＣＰＵへの
通信が停止された場合、監視ＣＰＵでの通信監視用デー
タが不変となり、それに伴い制御ＣＰＵの通信異常が検
出できる。その結果、制御ＣＰＵと監視ＣＰＵとを備え
る車両用電子制御装置において、制御ＣＰＵの通信異常
を精度良く検出することができる。

【０００６】特に請求項３に記載したように、監視ＣＰ
Ｕが受信割り込み機能を持たず、制御ＣＰＵからのデー
タ送信に同期して制御ＣＰＵへデータを返信する場合、
データ受信の有無により制御ＣＰＵの異常を検出するこ
とが困難になる。これに対し、請求項１，２の発明を用
いることで、通信監視用データにより制御ＣＰＵの異常
が容易に検出できる。この場合、低機能な監視ＣＰＵを
用いることが可能となり、コストダウンが実現できる。

【０００７】請求項４に記載の発明では、監視ＣＰＵ
は、前記通信監視用データを定期的にモニタし、当該デ
ータの今回値と前回値とが一致する場合、制御ＣＰＵか
らの通信が停止していると判定する。本構成によれば、
監視ＣＰＵでデータが正しく受信できない場合におい
て、その異常が通信停止によるものか、通信データの異
常によるものかが判別できる。

【０００８】請求項５に記載の発明では、監視ＣＰＵ
は、前記通信監視用データの今回値と前回値とが不一致
となる場合のみ、受信データの取り込みを許可する。本
構成によれば、例えば同一データが繰り返し受信される
場合において、実際に同一データを正しく受信したか、
或いは通信不良であったかが判別できる。

【０００９】請求項６に記載の発明では、前記通信監視
用データが所定時間以上更新されないと通信異常を判定
する構成とし、制御ＣＰＵが監視ＣＰＵにデータを送信
する時間間隔をＴ１とした場合に、監視ＣＰＵがＴ１≧
Ｔ２を満足する時間間隔Ｔ２にて前記通信監視用データ
をモニタする。この場合、通信監視用データのモニタ間
隔がデータ送信周期よりも短いため、通信監視用データ
が不変となる異常が漏れなく確実に検出でき、通信異常
検出までの時間が不用意に長引くといった事態が回避で
きる。

【００１０】また、請求項７に記載の発明では、監視Ｃ
ＰＵは、前記通信監視用データに基づく通信異常の検出
時にその旨をバックアップ用メモリに記憶保持し、その
通信異常が所定回検出された時、最終的に通信異常と判
定する。この場合、通信異常の誤検出が防止できる。

【００１１】請求項８に記載の発明では、通信データを
２分割し、制御ＣＰＵは２分割した通信データを交互に
監視ＣＰＵに対して送信する車両用電子制御装置であっ
て、２分割した通信データのうち、一方のデータ送信時
には前記通信監視用データを更新するだけで監視ＣＰＵ
に送信せず、他方のデータ送信時には前記通信監視用デ
ータを更新せずに監視ＣＰＵに送信する。要するに、通
信データ量が多い場合、該通信データが２分割して送信
されるが、かかる場合において２分割した通信データの
うち何れかのデータ送信が停止され、同一のデータが連
続して監視ＣＰＵに送信される異常が考えられる。この
異常発生時において、請求項８の発明によれば、何れの
データ送信が停止しても、通信監視用データに基づき異
常発生の旨が確実に検出できる。

【００１２】

【発明の実施の形態】（第１の実施の形態）以下、この
発明を具体化した第１の実施の形態を図面に従って説明
する。

【００１３】図１は、本実施の形態におけるエンジンＥ
ＣＵの構成を示すブロック図である。図１において、エ
ンジンＥＣＵ１０は、エンジンの噴射制御、点火制御及
び電子スロットル制御を実施するための制御ＣＰＵ１１
と、電子スロットル制御に関する監視制御を実施するた
めの監視ＣＰＵ１２と、制御ＣＰＵ１１の動作を監視す
るためのＷＤ回路１３とを備える。制御ＣＰＵ１１と監
視ＣＰＵ１２とは相互に通信可能に接続されている。制
御ＣＰＵ１１は、Ａ／Ｄ変換器１４を介してスロットル
開度やアクセル開度を入力する他に、エンジン回転数、
吸気管内圧力等々のエンジン運転情報を随時入力し、当
該運転情報に基づき図示しない燃料噴射弁、イグナイ
タ、スロットルアクチュエータの駆動を制御する。な
お、スロットル開度やアクセル開度のＡ／Ｄ値は監視Ｃ
ＰＵ１２にも入力される。

【００１４】制御ＣＰＵ１１と監視ＣＰＵ１２との間の
通信は、いわゆるＣＳＩ（ClockedSerial Interface）
方式が採用されており、各ＣＰＵ１１，１２間ではクロ
ック同期でデータの送受信が行われる。この場合、ＣＳ
Ｉ方式では送信と受信とが独立しておらず、監視ＣＰＵ
１２は制御ＣＰＵ１１からクロックとデータが来た時、
ハード的に制御ＣＰＵへデータを返信する構成となって
いる。つまり、監視ＣＰＵ１２は受信割り込み機能を持
っていない。

【００１５】制御ＣＰＵ１１は、監視ＣＰＵ１２の動作
を監視するための監視制御を実施する。すなわち、監視
ＣＰＵ１２は、制御ＣＰＵ１１に対して所定周期で反転
するＷＤパルスを出力し、制御ＣＰＵ１１は、監視ＣＰ
Ｕ１２からのＷＤパルスが所定時間以上反転しなかった
場合に監視ＣＰＵ１２に対してリセット信号を出力す
る。或いは、制御ＣＰＵ１１は、監視ＣＰＵ１２から正
常にデータを受信しない場合に監視ＣＰＵ１２に対して
リセット信号を出力する。

【００１６】また、制御ＣＰＵ１１は、監視ＣＰＵ１２
に対してスロットル開度、アクセル開度、フェイルセー
フ実施フラグ等、スロットル制御に関するデータを送信
する。このとき、監視ＣＰＵ１２は、スロットル制御の
監視処理として、例えばＡ／Ｄ変換器１４を通じて入力
したスロットル開度やアクセル開度のデータと、制御Ｃ
ＰＵ１１より受信した同じくスロットル開度やアクセル
開度のデータとを比較し、それらが一致するかどうかに
よりスロットル制御状態の異常を検出する。そして、そ
の監視結果を制御ＣＰＵ１１に対して返信する。

【００１７】また、制御ＣＰＵ１１は、監視ＣＰＵ１２
での監視結果に従い、スロットル制御の異常発生時に所
定のフェイルセーフ処理を実施する。フェイルセーフ処
理として具体的には、車両の退避走行（リンプホーム）
を実現すべく、一部の気筒の燃料噴射を休止させる減筒
制御や点火時期を遅角させる点火遅角制御等を実施す
る。

【００１８】更に、制御ＣＰＵ１１は、ＷＤ回路１３に
対して所定周期で反転するＷＤパルスを出力する。ＷＤ
回路１３は、制御ＣＰＵ１１からのＷＤパルスが所定時
間以上反転しなかった場合に制御ＣＰＵ１１に対してリ
セット信号を出力する。

【００１９】本実施の形態では特に、監視ＣＰＵ１２が
制御ＣＰＵ１１に対して直接リセットをかけることが可
能な構成としており、制御ＣＰＵ１１との通信が正しく
行われない場合、監視ＣＰＵ１２が制御ＣＰＵ１１にリ
セット信号を出力する。また本構成では、ＷＤ回路１３
からリセット信号を取り込むためのリセット端子に、監
視ＣＰＵ１２からのリセット信号を取り込むようにして
いる。これにより、ＷＤ回路１３又は監視ＣＰＵ１２の
何れかから制御ＣＰＵ１１にリセット信号が入力される
場合、該リセット信号により制御ＣＰＵ１１がリセット
されると共に、制御ＣＰＵ１１により監視ＣＰＵ１２も
同時にリセットされる。

【００２０】次に、制御ＣＰＵ１１と監視ＣＰＵ１２と
の間のＣＰＵ間通信の詳細を説明する。図２及び図３は
制御ＣＰＵ１１の処理を示すフローチャートであり、図
４は監視ＣＰＵ１２の処理を示すフローチャートであ
る。本実施の形態では、制御ＣＰＵ１１は、図２の４ｍ
ｓｅｃ処理により監視ＣＰＵ１２に対して定期的（４ｍ
ｓｅｃ毎）にデータ送信を行い、更に受信割り込みにて
図３の受信完了処理を実施する。また、監視ＣＰＵ１２
は、図４の２ｍｓｅｃ処理により制御ＣＰＵ１１の通信
異常の有無を判定する。以下、図２〜図４の処理を順に
説明する。

【００２１】制御ＣＰＵ１１による４ｍｓｅｃ処理（図
２）において、先ずステップ１０１では、「通信監視用
データ」としての通信回数カウンタＣＭＳを１インクリ
メントし、続くステップ１０２では、監視ＣＰＵ１２に
対してデータを送信する。このとき、前記通信回数カウ
ンタＣＭＳを付加してデータ送信を行う。その後、ステ
ップ１０３では、通信停止時間カウンタＣＳ１を１イン
クリメントし、続くステップ１０４では、通信停止時間
カウンタＣＳ１が所定時間相当の値（本実施の形態では
４８ｍｓｅｃ相当の値）よりも大きくなったか否かを判
別する。ＹＥＳの場合、監視ＣＰＵ１２の通信異常であ
るとみなし、ステップ１０５で通信異常フラグＸＮＧ１
をＯＮする。また、ステップ１０６では、受信データ異
常回数カウンタＣＥ１が所定回数（本実施の形態では２
０回）よりも大きいか否かを判別する。ＣＥ１＞２０回
の場合、監視ＣＰＵ１２の通信異常であるとみなし、ス
テップ１０７で通信異常フラグＸＮＧ１をＯＮする。

【００２２】その後、ステップ１０８では、通信異常フ
ラグＸＮＧ１がＯＮであるか否かを判別する。ＸＮＧ１
＝ＯＮの場合ステップ１０９に進み、監視ＣＰＵ１２に
対してリセット信号を出力し、当該ＣＰＵ１２にリセッ
トをかける。

【００２３】また、制御ＣＰＵ１１による受信完了処理
（図３）において、ステップ２０１では、通信停止時間
カウンタＣＳ１を０にクリアし、ステップ２０２では、
受信データが異常であるか否かを判別する。このとき、
受信データの異常検出は、周知のサムチェック、或いは
パリティチェック等により実施される。受信データ正常
の場合ステップ２０３に進み、受信データ異常回数カウ
ンタＣＥ１を０にクリアする。また、受信データ異常の
場合ステップ２０４に進み、受信データ異常回数カウン
タＣＥ１を１インクリメントする。

【００２４】一方、監視ＣＰＵ１２による２ｍｓｅｃ処
理（図４）において、先ずステップ３０１では、通信回
数カウンタＣＭＳの今回値と前回値＋１とが一致するか
否かを判別する。一致する場合ステップ３０２に進み、
通信停止時間カウンタＣＳ２を０にクリアし、一致しな
い場合ステップ３０３に進み、通信停止時間カウンタＣ
Ｓ２を１インクリメントする。その後、ステップ３０４
では、通信回数カウンタＣＭＳの今回値を前回値として
更新する。

【００２５】ステップ３０５では、通信停止時間カウン
タＣＳ２が所定時間相当の値（本実施の形態では１００
ｍｓｅｃ相当の値）よりも大きくなったか否かを判別す
る。ＹＥＳの場合、制御ＣＰＵ１１の通信異常であると
みなし、ステップ３０６で通信異常フラグＸＮＧ２をＯ
Ｎする。

【００２６】その後、ステップ３０７では、サムチェッ
クやパリティチェック等により受信データが異常である
か否かを判別する。受信データ正常の場合ステップ３０
８に進み、受信データ異常回数カウンタＣＥ２を０にク
リアする。また、受信データ異常の場合ステップ３０９
に進み、受信データ異常回数カウンタＣＥ２を１インク
リメントする。また、ステップ３１０では、受信データ
異常回数カウンタＣＥ２が所定回数（本実施の形態では
２０回）よりも大きいか否かを判別する。ＣＥ２＞２０
回の場合、制御ＣＰＵ１１の通信異常であるとみなし、
ステップ３１１で通信異常フラグＸＮＧ２をＯＮする。

【００２７】その後、ステップ３１２では、通信異常フ
ラグＸＮＧ２がＯＮであるか否かを判別する。ＸＮＧ２
＝ＯＮの場合ステップ３１３に進み、制御ＣＰＵ１１に
対してリセット信号を出力し、当該ＣＰＵ１１にリセッ
トをかける。

【００２８】図５は、上記図２〜図４の処理をより具体
的に説明するためのタイムチャートである。図５におい
て、（ａ）は制御ＣＰＵ１１の動作を、（ｂ）は監視Ｃ
ＰＵ１２の動作を示し、更にタイミングｔ１以前は通信
異常が発生していない状態を、タイミングｔ１以後は通
信異常が発生した後の状態を示す。なお、図５は、制御
ＣＰＵ１１から監視ＣＰＵ１２への通信が途絶えた場合
の異常を例示している。

【００２９】制御ＣＰＵ１１では、４ｍｓｅｃ周期で通
信回数カウンタＣＭＳがカウントアップされる。これに
対し、監視ＣＰＵ１２では、２ｍｓｅｃ周期で通信回数
カウンタＣＭＳの値がモニタされる。この場合、タイミ
ングｔ１以前は、監視ＣＰＵ１２が制御ＣＰＵ１１での
ＣＭＳ動作を正しく受信するため、通信停止時間カウン
タＣＳ２が０，１の値を繰り返すだけであり、この期間
では通信異常フラグＸＮＧ１，ＸＮＧ２がＯＦＦのまま
保持される。

【００３０】タイミングｔ１で制御ＣＰＵ１１から監視
ＣＰＵ１２への通信が途絶えると、監視ＣＰＵ１２で通
信データが受信できなくなる。故に、監視ＣＰＵ１２で
の通信回数カウンタＣＭＳのカウントアップ動作が止ま
り、これに代わって通信停止時間カウンタＣＳ２がカウ
ントアップされる。そして、通信停止時間カウンタＣＳ
２が１００ｍｓｅｃ相当の値に達すると（タイミングｔ
２）、通信異常フラグＸＮＧ２がＯＮされ、それに伴い
監視ＣＰＵ１２により制御ＣＰＵ１１がリセットされ
る。制御ＣＰＵ１１にリセットがかかる時、制御ＣＰＵ
１１により監視ＣＰＵ１２にもリセットがかかる。リセ
ット後に各ＣＰＵ１１，１２が再起動される時、カウン
タ等が初期化される。

【００３１】ここで、各ＣＰＵ１１，１２には、バック
アップ用メモリとしてのスタンバイＲＡＭが各々設けら
れており、通信異常フラグＸＮＧ１，ＸＮＧ２はこのス
タンバイＲＡＭに格納される。それ故、通信異常フラグ
ＸＮＧ１，ＸＮＧ２の状態はリセット後も保持される。
そして、通信回数カウンタＣＭＳによる通信異常が再度
検出されると、最終的に通信異常と判断され、警告ラン
プ等により異常発生の旨がユーザに警告される。なお、
３回以上通信異常が検出された時、最終的に通信異常と
判断する構成であっても良い。

【００３２】以上詳述した本実施の形態によれば、以下
に示す効果が得られる。制御ＣＰＵ１１から送信される
通信回数カウンタＣＭＳ（通信監視用データ）が更新さ
れているかどうかにより監視ＣＰＵ１２が制御ＣＰＵ１
１の通信異常を判定するので、その異常判定が容易に且
つ精度良く実施できる。特に、監視ＣＰＵ１２が受信割
り込み機能を持たない構成であっても、制御ＣＰＵの異
常検出が可能となる。この場合、低機能な監視ＣＰＵ１
２を用いることが可能となり、コストダウンが実現でき
る。

【００３３】また、通信回数カウンタＣＭＳのモニタ間
隔（２ｍｓｅｃ）がデータ送信周期（４ｍｓｅｃ）より
も短いため、通信回数カウンタＣＭＳが不変となる異常
が漏れなく確実に検出でき、通信異常検出までの時間が
不用意に長引くといった事態が回避できる。

【００３４】また、監視ＣＰＵ１２でデータが正しく受
信できない異常発生時において、その異常が通信停止に
よるものか、通信データの異常によるものかを判別する
ことができる。すなわち、通信回数カウンタＣＭＳの今
回値と前回値とが一致する場合、制御ＣＰＵ１１からの
通信停止による異常であると判定できる。この場合、例
えば異常データが関係するブロックのみを初期化する
等、異常の状態に応じてより細かな制御が実現できる。

【００３５】また、通信異常の検出結果（フラグ情報Ｘ
ＮＧ１，ＸＮＧ２）をスタンバイＲＡＭに記憶保持し、
その通信異常が所定回数に達した時に最終的に通信異常
と判定するため、通信異常の誤検出が防止できる。

【００３６】（第２の実施の形態）次に、本発明におけ
る第２の実施の形態について、上述した第１の実施の形
態との相違点を中心に説明する。本実施の形態では、通
信データ量が多く、通信を２回（通信Ａ、通信Ｂ）に分
けて行う場合において、通信回数カウンタＣＭＳを通信
Ａ、通信Ｂの何れか一方でのみ更新する。また、本来は
通信Ａ，Ｂを交互に実施する構成に対して通信Ａ，Ｂの
何れかのみが連続して実施される異常時にその異常を図
６の処理にて検出することとしている。

【００３７】図６は、通信データを通信Ａ、通信Ｂに２
分割する場合における定期的なデータ送信処理を示すフ
ローチャートである。図６において、（ａ）は通信Ａを
行うための４ｍｓｅｃ処理、（ｂ）は通信Ｂを行うため
の４ｍｓｅｃ処理をそれぞれ示しており、これら各処理
は等間隔で交互に実施される。また、これら各処理は前
記図２に置き換えて制御ＣＰＵ１１により実施され、ス
テップ１０３以降の処理は前記図２に準ずる。なお、監
視ＣＰＵ１２の処理は前記図４の処理をそのまま用いる
ため、ここではその説明を省略する。

【００３８】図６（ａ）において、ステップ４０１で
は、通信回数カウンタＣＭＳを１インクリメントし、続
くステップ４０２では、通信Ａとして監視ＣＰＵ１２に
対してデータａを送信する。このとき、通信回数カウン
タＣＭＳを付加せず、データａのみを送信する。ステッ
プ１０３以降は前述の通りである。

【００３９】一方、図６（ｂ）において、ステップ５０
１では、通信Ｂとして監視ＣＰＵ１２に対してデータｂ
を送信する。このとき、前記図６（ａ）にてインクリメ
ントした通信回数カウンタＣＭＳを付加してデータｂを
送信する。ステップ１０３以降は前述の通りである。

【００４０】図７は、上記図６の処理をより具体的に説
明するためのタイムチャートであり、同図には通信正常
時における基本動作を示す。図の（ａ）は制御ＣＰＵ１
１での動作を、（ｂ）は監視ＣＰＵ１２での動作を示
す。

【００４１】図７では、制御ＣＰＵ１１から監視ＣＰＵ
１２に対してデータａとデータｂとが交互に一定周期で
送信される。このとき、データａの送信時に通信回数カ
ウンタＣＭＳがカウントアップされ、データｂの送信時
に同カウンタＣＭＳが監視ＣＰＵ１２に送信される。ま
た、監視ＣＰＵ１２では、データａ，ｂの受信毎に通信
回数カウンタＣＭＳの保持とカウントアップが繰り返さ
れ、それに伴い通信停止時間カウンタＣＳ２が０，１の
値を繰り返す。故に、通信異常フラグＸＮＧ２がＯＮさ
れることはない。

【００４２】また、図８は通信Ａが連続する異常、図９
は通信Ｂが連続する異常をそれぞれ説明するためのタイ
ムチャートである。図の（ａ）は制御ＣＰＵ１１での動
作を、（ｂ）は監視ＣＰＵ１２での動作を示す。

【００４３】図８では、制御ＣＰＵ１１からデータａが
連続して送信され、その都度制御ＣＰＵ１１側で通信回
数カウンタＣＭＳがカウントアップされる。但し、通信
Ｂが実施されないため、ＣＭＳ値が監視ＣＰＵ１２に送
信されることはない。このとき、監視ＣＰＵ１２では、
通信回数カウンタＣＭＳの値が不変となるため、通信停
止時間カウンタＣＳ２が次第にカウントアップされる。
従って、ＣＳ２値が所定値に達した時に通信異常フラグ
ＸＮＧ２がＯＮされる。

【００４４】一方、図９では、制御ＣＰＵ１１からデー
タｂが連続して送信され、制御ＣＰＵ１１側で通信回数
カウンタＣＭＳの値が不変となる。このとき、監視ＣＰ
Ｕ１２でも同様に通信回数カウンタＣＭＳの値が不変と
なるため、通信停止時間カウンタＣＳ２が次第にカウン
トアップされる。従って、ＣＳ２値が所定値に達した時
に通信異常フラグＸＮＧ２がＯＮされる。

【００４５】以上本実施の形態によれば、２分割された
通信Ａ、通信Ｂのどちらが抜けた場合でも通信回数カウ
ンタＣＭＳにより通信異常が確実に検出できる。またこ
の場合、通信Ａ，Ｂのうち、一方でのみ通信回数カウン
タＣＭＳがカウントアップされるため、その分各ＣＰＵ
１１，１２での負荷が軽減される。

【００４６】なお本発明は、上記以外に次の形態にて具
体化できる。監視ＣＰＵ１２において、通信回数カウン
タＣＭＳ（通信監視用データ）の今回値と前回値とが不
一致となる場合のみ、受信データの取り込みを許可す
る。本構成によれば、例えば同一データが繰り返し受信
される場合において、実際に同一データを正しく受信し
たか、或いは通信不良であったかが判別できる。また、
制御ＣＰＵ１１から同じデータがｎ回送信される場合に
は、通信回数カウンタＣＭＳがｎ回更新されたか否かを
判別し、その通信異常を判定するようにしても良い。

【００４７】上記実施の形態では、「通信監視用デー
タ」として通信回数カウンタＣＭＳを用い、該カウンタ
ＣＭＳにより制御ＣＰＵ１１の通信異常を検出したが、
「通信監視用データ」として、フラグ情報を用いるな
ど、他の構成を用いても良い。また、通信回数カウンタ
ＣＭＳを用いる場合において、カウンタ値更新の幅を適
宜変更することも可能である。要は、通信の都度変化す
るよう通信監視用データが構成されれば良い。

【００４８】上記実施の形態では、通信異常の検出結果
（フラグ情報ＸＮＧ１，ＸＮＧ２）をスタンバイＲＡＭ
に記憶保持したが、その構成を無くし、毎回の通信異常
の検出の都度、警告ランプ等により異常発生の旨をユー
ザに警告する構成であっても良い。

【００４９】上記実施の形態では、監視ＣＰＵ１２が制
御ＣＰＵ１１の通信異常を検出した時、その監視ＣＰＵ
１２が制御ＣＰＵ１１にリセットをかける構成とした
が、その構成を変更することも可能である。例えば、制
御ＣＰＵ１１の通信異常時に、監視ＣＰＵ１２がその旨
を制御ＣＰＵ１１側に通知する構成であっても良い。

【図面の簡単な説明】

【図１】発明の実施の形態におけるエンジンＥＣＵの概
要を示す構成図。

【図２】制御ＣＰＵによる４ｍｓｅｃ処理を示すフロー
チャート。

【図３】制御ＣＰＵによる受信完了処理を示すフローチ
ャート。

【図４】監視ＣＰＵによる２ｍｓｅｃ処理を示すフロー
チャート。

【図５】通信動作を具体的に示すタイムチャート。

【図６】制御ＣＰＵによる４ｍｓｅｃ処理を示すフロー
チャート。

【図７】通信動作を具体的に示すタイムチャート。

【図８】通信動作を具体的に示すタイムチャート。

【図９】通信動作を具体的に示すタイムチャート。

【符号の説明】

１０…エンジンＥＣＵ、１１…制御ＣＰＵ、１２…監視
ＣＰＵ。

Claims

【特許請求の範囲】

【請求項１】各種の車両制御を実施する制御ＣＰＵと、
該制御ＣＰＵに対して通信可能に接続され、制御ＣＰＵ
の動作を監視する監視ＣＰＵとを備える車両用電子制御
装置において、制御ＣＰＵは、監視ＣＰＵへのデータ送信の都度、前回
送信時とは異なる通信監視用データを付してデータ送信
を行い、監視ＣＰＵは、前記通信監視用データが更新さ
れているかどうかにより通信異常を判定することを特徴
とする車両用電子制御装置。
【請求項２】前記通信監視用データは、データ送信の都
度更新されるカウンタ値である請求項１記載の車両用電
子制御装置。
【請求項３】監視ＣＰＵが受信割り込み機能を持たず、
制御ＣＰＵからのデータ送信に同期して制御ＣＰＵへデ
ータを返信する請求項１又は２記載の車両用電子制御装
置。
【請求項４】監視ＣＰＵは、前記通信監視用データを定
期的にモニタし、当該データの今回値と前回値とが一致
する場合、制御ＣＰＵからの通信が停止していると判定
する請求項１乃至３の何れかに記載の車両用電子制御装
置。
【請求項５】監視ＣＰＵは、前記通信監視用データの今
回値と前回値とが不一致となる場合のみ、受信データの
取り込みを許可する請求項１乃至４の何れかに記載の車
両用電子制御装置。
【請求項６】前記通信監視用データが所定時間以上更新
されないと通信異常を判定する構成とし、制御ＣＰＵが
監視ＣＰＵにデータを送信する時間間隔をＴ１とした場
合に、監視ＣＰＵがＴ１≧Ｔ２を満足する時間間隔Ｔ２
にて前記通信監視用データをモニタする請求項１乃至５
の何れかに記載の車両用電子制御装置。
【請求項７】監視ＣＰＵは、前記通信監視用データに基
づく通信異常の検出時にその旨をバックアップ用メモリ
に記憶保持し、その通信異常が所定回検出された時、最
終的に通信異常と判定する請求項１乃至６の何れかに記
載の車両用電子制御装置。
【請求項８】通信データを２分割し、制御ＣＰＵは２分
割した通信データを交互に監視ＣＰＵに対して送信する
車両用電子制御装置であって、２分割した通信データの
うち、一方のデータ送信時には前記通信監視用データを
更新するだけで監視ＣＰＵに送信せず、他方のデータ送
信時には前記通信監視用データを更新せずに監視ＣＰＵ
に送信する請求項１乃至７の何れかに記載の車両用電子
制御装置。