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