JP3901987B2

JP3901987B2 - 車両用電子制御装置

Info

Publication number: JP3901987B2
Application number: JP2001334366A
Authority: JP
Inventors: 稔昌小林; 啓晴竹内; 剛博城向
Original assignee: Denso Corp; Toyota Motor Corp
Current assignee: Denso Corp; Toyota Motor Corp
Priority date: 2001-10-31
Filing date: 2001-10-31
Publication date: 2007-04-04
Anticipated expiration: 2021-10-31
Also published as: JP2003137045A

Description

【０００１】
【発明の属する技術分野】
本発明は、各種の車両制御を実施する制御ＣＰＵとこの制御ＣＰＵを監視する監視ＣＰＵとを備える車両用電子制御装置に関するものである。
【０００２】
【従来の技術】
車載エンジンの制御を司る車両用電子制御装置（エンジンＥＣＵ）として、噴射制御及び点火制御を実施するための噴射・点火制御用ＣＰＵと、電子スロットル制御を実施するためのスロットル制御用ＣＰＵとからなる２つのＣＰＵを持つ構成が知られている。
【０００３】
これに対し近年では、ＣＰＵの高機能・大容量化により、従来２つのＣＰＵを使用して実現してきたエンジン制御（噴射・点火制御）と電子スロットル制御とを１つの制御ＣＰＵで構成し、エンジンＥＣＵのコストダウンを図ることが考えられる。このような１ＣＰＵ構成のエンジンＥＣＵでは、電子スロットル制御の状態を監視するための監視ＣＰＵが別途必要になる。この場合、監視ＣＰＵは監視専用であり低機能（安価）なものが採用されるため、監視ＣＰＵとして制御ＣＰＵの通信異常を精度良く検出できる構成が望まれている。特に制御ＣＰＵ側が全ての主導権を持ち、監視ＣＰＵ側では制御ＣＰＵからのデータ送信に同期してハード的にデータを返信する場合、監視ＣＰＵでは受信割り込み機能を持たず、制御ＣＰＵの通信異常を検出することが困難となる。
【０００４】
【発明が解決しようとする課題】
本発明は、上記問題に着目してなされたものであって、制御ＣＰＵと監視ＣＰＵとを備える車両用電子制御装置において、制御ＣＰＵの通信異常を精度良く検出することができる構成を提供することを目的とする。
【０００５】
【課題を解決するための手段】
請求項１に記載の発明では、各種の車両制御を実施する制御ＣＰＵと、該制御ＣＰＵに対して通信可能に接続され、制御ＣＰＵの動作を監視する監視ＣＰＵとを備え、通信の実行に際しては通信データを２分割し、制御ＣＰＵはこの２分割した通信データを交互に監視ＣＰＵに対して送信する車両用電子制御装置において、制御ＣＰＵは、２分割した通信データのうち、一方のデータ送信時には通信監視用データを更新するだけで監視ＣＰＵに送信せず、他方のデータ送信時には前記通信監視用データを更新せずに監視ＣＰＵに送信し、監視ＣＰＵは、前記通信監視用データが更新されているかどうかにより通信異常を判定する。なお、前記通信監視用データは、データ送信の都度更新されるカウンタ値であると良い（請求項２）。
制御ＣＰＵと監視ＣＰＵとの間における通信データ量が多い場合、該通信データが２分割して送信されるが、かかる場合において２分割した通信データのうち何れかのデータ送信が停止され、同一のデータが連続して監視ＣＰＵに送信される異常が考えられる。請求項１に記載の発明によれば、何れのデータ送信が停止した場合においても監視ＣＰＵでの通信監視用データが不変となり、それに伴い制御ＣＰＵの通信異常が検出できる。その結果、制御ＣＰＵと監視ＣＰＵとを備える車両用電子制御装置において、制御ＣＰＵの通信異常を精度良く検出することができる。
【０００６】
特に請求項３に記載したように、監視ＣＰＵが受信割り込み機能を持たず、制御ＣＰＵからのデータ送信に同期して制御ＣＰＵへデータを返信する場合、データ受信の有無により制御ＣＰＵの異常を検出することが困難になる。これに対し、請求項１，２の発明を用いることで、通信監視用データにより制御ＣＰＵの異常が容易に検出できる。この場合、低機能な監視ＣＰＵを用いることが可能となり、コストダウンが実現できる。
【０００７】
請求項４に記載の発明では、監視ＣＰＵは、前記通信監視用データを定期的にモニタし、当該データの今回値と前回値とが一致する場合、制御ＣＰＵからの通信が停止していると判定する。本構成によれば、監視ＣＰＵでデータが正しく受信できない場合において、その異常が通信停止によるものか、通信データの異常によるものかが判別できる。
【０００８】
請求項５に記載の発明では、監視ＣＰＵは、前記通信監視用データの今回値と前回値とが不一致となる場合のみ、受信データの取り込みを許可する。本構成によれば、例えば同一データが繰り返し受信される場合において、実際に同一データを正しく受信したか、或いは通信不良であったかが判別できる。
【０００９】
請求項６に記載の発明では、前記通信監視用データが所定時間以上更新されないと通信異常を判定する構成とし、制御ＣＰＵが監視ＣＰＵにデータを送信する時間間隔をＴ１とした場合に、監視ＣＰＵがＴ１≧Ｔ２を満足する時間間隔Ｔ２にて前記通信監視用データをモニタする。この場合、通信監視用データのモニタ間隔がデータ送信周期よりも短いため、通信監視用データが不変となる異常が漏れなく確実に検出でき、通信異常検出までの時間が不用意に長引くといった事態が回避できる。
【００１０】
また、請求項７に記載の発明では、監視ＣＰＵは、前記通信監視用データに基づく通信異常の検出時にその旨をバックアップ用メモリに記憶保持し、その通信異常が所定回検出された時、最終的に通信異常と判定する。この場合、通信異常の誤検出が防止できる。
【００１２】
【発明の実施の形態】
（第１の実施の形態）
以下、この発明を具体化した第１の実施の形態を図面に従って説明する。
【００１３】
図１は、本実施の形態におけるエンジンＥＣＵの構成を示すブロック図である。図１において、エンジンＥＣＵ１０は、エンジンの噴射制御、点火制御及び電子スロットル制御を実施するための制御ＣＰＵ１１と、電子スロットル制御に関する監視制御を実施するための監視ＣＰＵ１２と、制御ＣＰＵ１１の動作を監視するためのＷＤ回路１３とを備える。制御ＣＰＵ１１と監視ＣＰＵ１２とは相互に通信可能に接続されている。制御ＣＰＵ１１は、Ａ／Ｄ変換器１４を介してスロットル開度やアクセル開度を入力する他に、エンジン回転数、吸気管内圧力等々のエンジン運転情報を随時入力し、当該運転情報に基づき図示しない燃料噴射弁、イグナイタ、スロットルアクチュエータの駆動を制御する。なお、スロットル開度やアクセル開度のＡ／Ｄ値は監視ＣＰＵ１２にも入力される。
【００１４】
制御ＣＰＵ１１と監視ＣＰＵ１２との間の通信は、いわゆるＣＳＩ（Clocked Serial Interface）方式が採用されており、各ＣＰＵ１１，１２間ではクロック同期でデータの送受信が行われる。この場合、ＣＳＩ方式では送信と受信とが独立しておらず、監視ＣＰＵ１２は制御ＣＰＵ１１からクロックとデータが来た時、ハード的に制御ＣＰＵへデータを返信する構成となっている。つまり、監視ＣＰＵ１２は受信割り込み機能を持っていない。
【００１５】
制御ＣＰＵ１１は、監視ＣＰＵ１２の動作を監視するための監視制御を実施する。すなわち、監視ＣＰＵ１２は、制御ＣＰＵ１１に対して所定周期で反転するＷＤパルスを出力し、制御ＣＰＵ１１は、監視ＣＰＵ１２からのＷＤパルスが所定時間以上反転しなかった場合に監視ＣＰＵ１２に対してリセット信号を出力する。或いは、制御ＣＰＵ１１は、監視ＣＰＵ１２から正常にデータを受信しない場合に監視ＣＰＵ１２に対してリセット信号を出力する。
【００１６】
また、制御ＣＰＵ１１は、監視ＣＰＵ１２に対してスロットル開度、アクセル開度、フェイルセーフ実施フラグ等、スロットル制御に関するデータを送信する。このとき、監視ＣＰＵ１２は、スロットル制御の監視処理として、例えばＡ／Ｄ変換器１４を通じて入力したスロットル開度やアクセル開度のデータと、制御ＣＰＵ１１より受信した同じくスロットル開度やアクセル開度のデータとを比較し、それらが一致するかどうかによりスロットル制御状態の異常を検出する。そして、その監視結果を制御ＣＰＵ１１に対して返信する。
【００１７】
また、制御ＣＰＵ１１は、監視ＣＰＵ１２での監視結果に従い、スロットル制御の異常発生時に所定のフェイルセーフ処理を実施する。フェイルセーフ処理として具体的には、車両の退避走行（リンプホーム）を実現すべく、一部の気筒の燃料噴射を休止させる減筒制御や点火時期を遅角させる点火遅角制御等を実施する。
【００１８】
更に、制御ＣＰＵ１１は、ＷＤ回路１３に対して所定周期で反転するＷＤパルスを出力する。ＷＤ回路１３は、制御ＣＰＵ１１からのＷＤパルスが所定時間以上反転しなかった場合に制御ＣＰＵ１１に対してリセット信号を出力する。
【００１９】
本実施の形態では特に、監視ＣＰＵ１２が制御ＣＰＵ１１に対して直接リセットをかけることが可能な構成としており、制御ＣＰＵ１１との通信が正しく行われない場合、監視ＣＰＵ１２が制御ＣＰＵ１１にリセット信号を出力する。また本構成では、ＷＤ回路１３からリセット信号を取り込むためのリセット端子に、監視ＣＰＵ１２からのリセット信号を取り込むようにしている。これにより、ＷＤ回路１３又は監視ＣＰＵ１２の何れかから制御ＣＰＵ１１にリセット信号が入力される場合、該リセット信号により制御ＣＰＵ１１がリセットされると共に、制御ＣＰＵ１１により監視ＣＰＵ１２も同時にリセットされる。
【００２０】
次に、制御ＣＰＵ１１と監視ＣＰＵ１２との間のＣＰＵ間通信の詳細を説明する。図２及び図３は制御ＣＰＵ１１の処理を示すフローチャートであり、図４は監視ＣＰＵ１２の処理を示すフローチャートである。本実施の形態では、制御ＣＰＵ１１は、図２の４ｍｓｅｃ処理により監視ＣＰＵ１２に対して定期的（４ｍｓｅｃ毎）にデータ送信を行い、更に受信割り込みにて図３の受信完了処理を実施する。また、監視ＣＰＵ１２は、図４の２ｍｓｅｃ処理により制御ＣＰＵ１１の通信異常の有無を判定する。以下、図２〜図４の処理を順に説明する。
【００２１】
制御ＣＰＵ１１による４ｍｓｅｃ処理（図２）において、先ずステップ１０１では、「通信監視用データ」としての通信回数カウンタＣＭＳを１インクリメントし、続くステップ１０２では、監視ＣＰＵ１２に対してデータを送信する。このとき、前記通信回数カウンタＣＭＳを付加してデータ送信を行う。その後、ステップ１０３では、通信停止時間カウンタＣＳ１を１インクリメントし、続くステップ１０４では、通信停止時間カウンタＣＳ１が所定時間相当の値（本実施の形態では４８ｍｓｅｃ相当の値）よりも大きくなったか否かを判別する。ＹＥＳの場合、監視ＣＰＵ１２の通信異常であるとみなし、ステップ１０５で通信異常フラグＸＮＧ１をＯＮする。また、ステップ１０６では、受信データ異常回数カウンタＣＥ１が所定回数（本実施の形態では２０回）よりも大きいか否かを判別する。ＣＥ１＞２０回の場合、監視ＣＰＵ１２の通信異常であるとみなし、ステップ１０７で通信異常フラグＸＮＧ１をＯＮする。
【００２２】
その後、ステップ１０８では、通信異常フラグＸＮＧ１がＯＮであるか否かを判別する。ＸＮＧ１＝ＯＮの場合ステップ１０９に進み、監視ＣＰＵ１２に対してリセット信号を出力し、当該ＣＰＵ１２にリセットをかける。
【００２３】
また、制御ＣＰＵ１１による受信完了処理（図３）において、ステップ２０１では、通信停止時間カウンタＣＳ１を０にクリアし、ステップ２０２では、受信データが異常であるか否かを判別する。このとき、受信データの異常検出は、周知のサムチェック、或いはパリティチェック等により実施される。受信データ正常の場合ステップ２０３に進み、受信データ異常回数カウンタＣＥ１を０にクリアする。また、受信データ異常の場合ステップ２０４に進み、受信データ異常回数カウンタＣＥ１を１インクリメントする。
【００２４】
一方、監視ＣＰＵ１２による２ｍｓｅｃ処理（図４）において、先ずステップ３０１では、通信回数カウンタＣＭＳの今回値と前回値＋１とが一致するか否かを判別する。一致する場合ステップ３０２に進み、通信停止時間カウンタＣＳ２を０にクリアし、一致しない場合ステップ３０３に進み、通信停止時間カウンタＣＳ２を１インクリメントする。その後、ステップ３０４では、通信回数カウンタＣＭＳの今回値を前回値として更新する。
【００２５】
ステップ３０５では、通信停止時間カウンタＣＳ２が所定時間相当の値（本実施の形態では１００ｍｓｅｃ相当の値）よりも大きくなったか否かを判別する。ＹＥＳの場合、制御ＣＰＵ１１の通信異常であるとみなし、ステップ３０６で通信異常フラグＸＮＧ２をＯＮする。
【００２６】
その後、ステップ３０７では、サムチェックやパリティチェック等により受信データが異常であるか否かを判別する。受信データ正常の場合ステップ３０８に進み、受信データ異常回数カウンタＣＥ２を０にクリアする。また、受信データ異常の場合ステップ３０９に進み、受信データ異常回数カウンタＣＥ２を１インクリメントする。また、ステップ３１０では、受信データ異常回数カウンタＣＥ２が所定回数（本実施の形態では２０回）よりも大きいか否かを判別する。ＣＥ２＞２０回の場合、制御ＣＰＵ１１の通信異常であるとみなし、ステップ３１１で通信異常フラグＸＮＧ２をＯＮする。
【００２７】
その後、ステップ３１２では、通信異常フラグＸＮＧ２がＯＮであるか否かを判別する。ＸＮＧ２＝ＯＮの場合ステップ３１３に進み、制御ＣＰＵ１１に対してリセット信号を出力し、当該ＣＰＵ１１にリセットをかける。
【００２８】
図５は、上記図２〜図４の処理をより具体的に説明するためのタイムチャートである。図５において、（ａ）は制御ＣＰＵ１１の動作を、（ｂ）は監視ＣＰＵ１２の動作を示し、更にタイミングｔ１以前は通信異常が発生していない状態を、タイミングｔ１以後は通信異常が発生した後の状態を示す。なお、図５は、制御ＣＰＵ１１から監視ＣＰＵ１２への通信が途絶えた場合の異常を例示している。
【００２９】
制御ＣＰＵ１１では、４ｍｓｅｃ周期で通信回数カウンタＣＭＳがカウントアップされる。これに対し、監視ＣＰＵ１２では、２ｍｓｅｃ周期で通信回数カウンタＣＭＳの値がモニタされる。この場合、タイミングｔ１以前は、監視ＣＰＵ１２が制御ＣＰＵ１１でのＣＭＳ動作を正しく受信するため、通信停止時間カウンタＣＳ２が０，１の値を繰り返すだけであり、この期間では通信異常フラグＸＮＧ１，ＸＮＧ２がＯＦＦのまま保持される。
【００３０】
タイミングｔ１で制御ＣＰＵ１１から監視ＣＰＵ１２への通信が途絶えると、監視ＣＰＵ１２で通信データが受信できなくなる。故に、監視ＣＰＵ１２での通信回数カウンタＣＭＳのカウントアップ動作が止まり、これに代わって通信停止時間カウンタＣＳ２がカウントアップされる。そして、通信停止時間カウンタＣＳ２が１００ｍｓｅｃ相当の値に達すると（タイミングｔ２）、通信異常フラグＸＮＧ２がＯＮされ、それに伴い監視ＣＰＵ１２により制御ＣＰＵ１１がリセットされる。制御ＣＰＵ１１にリセットがかかる時、制御ＣＰＵ１１により監視ＣＰＵ１２にもリセットがかかる。リセット後に各ＣＰＵ１１，１２が再起動される時、カウンタ等が初期化される。
【００３１】
ここで、各ＣＰＵ１１，１２には、バックアップ用メモリとしてのスタンバイＲＡＭが各々設けられており、通信異常フラグＸＮＧ１，ＸＮＧ２はこのスタンバイＲＡＭに格納される。それ故、通信異常フラグＸＮＧ１，ＸＮＧ２の状態はリセット後も保持される。そして、通信回数カウンタＣＭＳによる通信異常が再度検出されると、最終的に通信異常と判断され、警告ランプ等により異常発生の旨がユーザに警告される。なお、３回以上通信異常が検出された時、最終的に通信異常と判断する構成であっても良い。
【００３２】
以上詳述した本実施の形態によれば、以下に示す効果が得られる。
制御ＣＰＵ１１から送信される通信回数カウンタＣＭＳ（通信監視用データ）が更新されているかどうかにより監視ＣＰＵ１２が制御ＣＰＵ１１の通信異常を判定するので、その異常判定が容易に且つ精度良く実施できる。特に、監視ＣＰＵ１２が受信割り込み機能を持たない構成であっても、制御ＣＰＵの異常検出が可能となる。この場合、低機能な監視ＣＰＵ１２を用いることが可能となり、コストダウンが実現できる。
【００３３】
また、通信回数カウンタＣＭＳのモニタ間隔（２ｍｓｅｃ）がデータ送信周期（４ｍｓｅｃ）よりも短いため、通信回数カウンタＣＭＳが不変となる異常が漏れなく確実に検出でき、通信異常検出までの時間が不用意に長引くといった事態が回避できる。
【００３４】
また、監視ＣＰＵ１２でデータが正しく受信できない異常発生時において、その異常が通信停止によるものか、通信データの異常によるものかを判別することができる。すなわち、通信回数カウンタＣＭＳの今回値と前回値とが一致する場合、制御ＣＰＵ１１からの通信停止による異常であると判定できる。この場合、例えば異常データが関係するブロックのみを初期化する等、異常の状態に応じてより細かな制御が実現できる。
【００３５】
また、通信異常の検出結果（フラグ情報ＸＮＧ１，ＸＮＧ２）をスタンバイＲＡＭに記憶保持し、その通信異常が所定回数に達した時に最終的に通信異常と判定するため、通信異常の誤検出が防止できる。
【００３６】
（第２の実施の形態）
次に、本発明における第２の実施の形態について、上述した第１の実施の形態との相違点を中心に説明する。本実施の形態では、通信データ量が多く、通信を２回（通信Ａ、通信Ｂ）に分けて行う場合において、通信回数カウンタＣＭＳを通信Ａ、通信Ｂの何れか一方でのみ更新する。また、本来は通信Ａ，Ｂを交互に実施する構成に対して通信Ａ，Ｂの何れかのみが連続して実施される異常時にその異常を図６の処理にて検出することとしている。
【００３７】
図６は、通信データを通信Ａ、通信Ｂに２分割する場合における定期的なデータ送信処理を示すフローチャートである。図６において、（ａ）は通信Ａを行うための４ｍｓｅｃ処理、（ｂ）は通信Ｂを行うための４ｍｓｅｃ処理をそれぞれ示しており、これら各処理は等間隔で交互に実施される。また、これら各処理は前記図２に置き換えて制御ＣＰＵ１１により実施され、ステップ１０３以降の処理は前記図２に準ずる。なお、監視ＣＰＵ１２の処理は前記図４の処理をそのまま用いるため、ここではその説明を省略する。
【００３８】
図６（ａ）において、ステップ４０１では、通信回数カウンタＣＭＳを１インクリメントし、続くステップ４０２では、通信Ａとして監視ＣＰＵ１２に対してデータａを送信する。このとき、通信回数カウンタＣＭＳを付加せず、データａのみを送信する。ステップ１０３以降は前述の通りである。
【００３９】
一方、図６（ｂ）において、ステップ５０１では、通信Ｂとして監視ＣＰＵ１２に対してデータｂを送信する。このとき、前記図６（ａ）にてインクリメントした通信回数カウンタＣＭＳを付加してデータｂを送信する。ステップ１０３以降は前述の通りである。
【００４０】
図７は、上記図６の処理をより具体的に説明するためのタイムチャートであり、同図には通信正常時における基本動作を示す。図の（ａ）は制御ＣＰＵ１１での動作を、（ｂ）は監視ＣＰＵ１２での動作を示す。
【００４１】
図７では、制御ＣＰＵ１１から監視ＣＰＵ１２に対してデータａとデータｂとが交互に一定周期で送信される。このとき、データａの送信時に通信回数カウンタＣＭＳがカウントアップされ、データｂの送信時に同カウンタＣＭＳが監視ＣＰＵ１２に送信される。また、監視ＣＰＵ１２では、データａ，ｂの受信毎に通信回数カウンタＣＭＳの保持とカウントアップが繰り返され、それに伴い通信停止時間カウンタＣＳ２が０，１の値を繰り返す。故に、通信異常フラグＸＮＧ２がＯＮされることはない。
【００４２】
また、図８は通信Ａが連続する異常、図９は通信Ｂが連続する異常をそれぞれ説明するためのタイムチャートである。図の（ａ）は制御ＣＰＵ１１での動作を、（ｂ）は監視ＣＰＵ１２での動作を示す。
【００４３】
図８では、制御ＣＰＵ１１からデータａが連続して送信され、その都度制御ＣＰＵ１１側で通信回数カウンタＣＭＳがカウントアップされる。但し、通信Ｂが実施されないため、ＣＭＳ値が監視ＣＰＵ１２に送信されることはない。このとき、監視ＣＰＵ１２では、通信回数カウンタＣＭＳの値が不変となるため、通信停止時間カウンタＣＳ２が次第にカウントアップされる。従って、ＣＳ２値が所定値に達した時に通信異常フラグＸＮＧ２がＯＮされる。
【００４４】
一方、図９では、制御ＣＰＵ１１からデータｂが連続して送信され、制御ＣＰＵ１１側で通信回数カウンタＣＭＳの値が不変となる。このとき、監視ＣＰＵ１２でも同様に通信回数カウンタＣＭＳの値が不変となるため、通信停止時間カウンタＣＳ２が次第にカウントアップされる。従って、ＣＳ２値が所定値に達した時に通信異常フラグＸＮＧ２がＯＮされる。
【００４５】
以上本実施の形態によれば、２分割された通信Ａ、通信Ｂのどちらが抜けた場合でも通信回数カウンタＣＭＳにより通信異常が確実に検出できる。またこの場合、通信Ａ，Ｂのうち、一方でのみ通信回数カウンタＣＭＳがカウントアップされるため、その分各ＣＰＵ１１，１２での負荷が軽減される。
【００４６】
なお本発明は、上記以外に次の形態にて具体化できる。
監視ＣＰＵ１２において、通信回数カウンタＣＭＳ（通信監視用データ）の今回値と前回値とが不一致となる場合のみ、受信データの取り込みを許可する。本構成によれば、例えば同一データが繰り返し受信される場合において、実際に同一データを正しく受信したか、或いは通信不良であったかが判別できる。また、制御ＣＰＵ１１から同じデータがｎ回送信される場合には、通信回数カウンタＣＭＳがｎ回更新されたか否かを判別し、その通信異常を判定するようにしても良い。
【００４７】
上記実施の形態では、「通信監視用データ」として通信回数カウンタＣＭＳを用い、該カウンタＣＭＳにより制御ＣＰＵ１１の通信異常を検出したが、「通信監視用データ」として、フラグ情報を用いるなど、他の構成を用いても良い。また、通信回数カウンタＣＭＳを用いる場合において、カウンタ値更新の幅を適宜変更することも可能である。要は、通信の都度変化するよう通信監視用データが構成されれば良い。
【００４８】
上記実施の形態では、通信異常の検出結果（フラグ情報ＸＮＧ１，ＸＮＧ２）をスタンバイＲＡＭに記憶保持したが、その構成を無くし、毎回の通信異常の検出の都度、警告ランプ等により異常発生の旨をユーザに警告する構成であっても良い。
【００４９】
上記実施の形態では、監視ＣＰＵ１２が制御ＣＰＵ１１の通信異常を検出した時、その監視ＣＰＵ１２が制御ＣＰＵ１１にリセットをかける構成としたが、その構成を変更することも可能である。例えば、制御ＣＰＵ１１の通信異常時に、監視ＣＰＵ１２がその旨を制御ＣＰＵ１１側に通知する構成であっても良い。
【図面の簡単な説明】
【図１】発明の実施の形態におけるエンジンＥＣＵの概要を示す構成図。
【図２】制御ＣＰＵによる４ｍｓｅｃ処理を示すフローチャート。
【図３】制御ＣＰＵによる受信完了処理を示すフローチャート。
【図４】監視ＣＰＵによる２ｍｓｅｃ処理を示すフローチャート。
【図５】通信動作を具体的に示すタイムチャート。
【図６】制御ＣＰＵによる４ｍｓｅｃ処理を示すフローチャート。
【図７】通信動作を具体的に示すタイムチャート。
【図８】通信動作を具体的に示すタイムチャート。
【図９】通信動作を具体的に示すタイムチャート。
【符号の説明】
１０…エンジンＥＣＵ、１１…制御ＣＰＵ、１２…監視ＣＰＵ。

Claims

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