(57)【特許請求の範囲】
【請求項１】
複数のコントロールユニットが相互にデータ通信可能に構築された車両用ネットワークの通信復帰判定方法であって、
任意のコントロールユニットについて通信エラーが検出されると、該エラーの回数を積算する第１のステップと、
該エラーの回数が所定回数に達すると、異常状態であると判定して該任意のコントロールユニットの通信を一旦停止させる第２のステップと、
該通信を停止させてから所定時間経過後に該任意のコントロールユニットの通信を試みる第３のステップと、
該第３のステップによる通信でエラーが生じたか否かを判定する第４のステップとをそなえ、
該第４のステップで通信エラーが生じていないと判定されると、システムが正常に復帰したものとして通常の通信を再開させる
ことを特徴とする、車両用ネットワークの通信復帰判定方法。
【請求項２】
該第４のステップで通信エラーが生じたと判定されると、該通信エラーが検出されなくなるまで該第３のステップで所定時間毎に通信を試みる
ことを特徴とする、請求項１記載の車両用ネットワークの通信復帰判定方法。
【請求項３】
該所定時間が、制御の重要度に応じて各コントロールユニットで個別に設定されている
ことを特徴とする、請求項１又は２記載の車両用ネットワークの通信復帰判定方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、車両用ネットワークの通信復帰判定方法に関する。
【０００２】
【従来の技術】
近年、自動車のエンジンやトランスミッション等の各種の機器の電子制御化にともない、これらの機器にはコントロールユニット（ＥＣＵ）が装備されつつある。そして、このような各ＥＣＵを、相互に通信可能に構成するべくネットワーク化が図られている。
【０００３】
この場合、従来では１つの信号に対して１つのケーブルを割り当てていたが、このような手法では、各機器間のデータ通信量の増大にともないワイヤハーネス類の数が膨大のものとなり、ワイヤハーネス類の配設が非常に複雑なものとなってしまう。
そこで、自動車用のネットワークの１つとして、ＣＡＮ（Controller  Area  Network）と呼ばれるシリアルバスシステムが提案されている。
【０００４】
ＣＡＮは、主に複数のＥＣＵを通信線（ＣＡＮバス）で接続し、相互にデータ通信を行なうシステムであり、ＩＳＯ（国際標準化機構）でその規格が定義されている。また、ＳＡＥ（米国自動車技術会）のＪ１９３９においても、ＣＡＮを自動車に適用する際の細かい取り決めがなされている。
ところで、ＣＡＮには、通信のエラーを検出するための機能が設けられている。このエラー検出の手法について簡単に説明すると、データを送信した側のＥＣＵでは、ＣＡＮバス上の実信号がモニタされており、送信データとバス上のデータとを比較してこれらのデータが一致していれば正しく通信が行なわれたと判定し、一致していなければ通信エラーと判定するのである。
【０００５】
【発明が解決しようとする課題】
次に、通信エラーの判定時の処理について説明すると、これには、主に図８（ａ），（ｂ）に示すような２つのパターンが考えられる。
まず、図８（ａ）に示すパターン１について説明すると、ＣＡＮ通信が行なわれ（ステップＳ１０）、この際に送信側ＥＣＵで通信エラーが検出されると、エラーの回数が積算される（ステップＳ２０）。そして、エラー回数のカウント値が２５６に達するまでは、通常どおりＣＡＮ通信を許容し、カウント値が２５６になると、送信側のＥＣＵの通信を停止させる（ステップＳ３０）。その後エラーのカウント値をリセットするとともに所定時間後に通信を再開する（ステップＳ４０）。なお、通信エラーの回数が２５６回累積すると一旦通信を停止させるのは、ＣＡＮのプロトコルによるものである。
【０００６】
ここで、このパターン１は、例えばバスラインの接触不良による一時的なエラーを考慮したものである。つまり、接触不良によりバスラインが断線してエラーが発生したとしても、その後接触状態がよくなることが考えられるからであり、このような場合を期待して、所定時間後に通信を再開するのである。なお、バスラインの接触状態が正常に戻らなければ、再び２５６回の通信エラーをカウント後、通信を停止させ、以降は同様の処理が繰り返される。
【０００７】
次に、図８（ｂ）に示すパターン２について説明すると、ステップＳ５０〜Ｓ７０までは、パターン１のステップＳ１０〜Ｓ３０までと同様の処理を行ない、ステップＳ７０で通信を停止させた後は、そのままエラーの発生したＥＣＵの作動を強制的に終了させる（ステップＳ８０）。この場合、再度車両がキーオン（電源オン）されるまで通信が中止されることになる。
【０００８】
しかしながら、このような従来の手法では、以下のような課題があった。すなわち、パターン１の場合、ＣＡＮバスの異常状態から正常状態への復帰を判定することができるが、ＣＡＮバスがある周波数以上で周期的にオンオフを繰り返すような接触不良状態に陥ったときに、ＥＣＵの通信停止（ステップＳ３０）及びエラーリセット（ステップＳ４０）の繰り返しにより、送信中の信号が途中で切れたりするためバスライン上のエラーデータが増大して、接触不良に無関係なラインの通信を止めてしまうという課題がある。なお、この場合全ＥＣＵの通信がストップしてしまうことを実験で確認済みである。
【０００９】
一方、パターン２の場合には、通信エラーの回数が２５６回に達すると強制的にＥＣＵの通信を終了させるため、上記のパターン１のようにエラーデータがＣＡＮバス上で増大して他のＥＣＵの通信に影響を与えるということはないものの、バスラインが正常状態へ復帰しても、次回のキーオンまでこのような復帰を判定することができないという課題がある。また、バスラインが正常状態に戻っても通信が止まったままであるので、制御上重要なデータのやり取りができなくなるという課題がある。
【００１０】
ところで、実公平５−２００２７号公報には、エラー信号を検出すると電源供給を遮断するとともに、一定時間後に電源供給を再開させるようにした技術が開示されている。しかしながら、この技術では、エラー信号検出時に電源のオンオフを行なうため、正常に送受信可能な他のＥＣＵの通信も停止させてしまうという課題がある。また、実開平５−７４０４０号公報及び特開平１−１２９５４９号公報にもＬＡＮに関する技術が開示されているものの、やはり上述の課題を何ら解決するものではなかった。なお、ＳＡＥには、通信エラーが生じて通信を停止した後の処理に関しては特段の規定はない。
【００１１】
本発明は、このような課題に鑑み創案されたもので、バスラインの一時的な異常時に他の正常なシステムに影響を与えことなく、復帰判定を行なえるようにした、車両用ネットワークの通信復帰判定方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
このため、請求項１にかかる本発明の車両用ネットワークの通信復帰判定方法では、複数のコントロールユニットが通信線で接続されて相互にデータ通信可能に構築され、任意のコントロールユニットにおいて通信エラーが検出されると、エラーの回数が積算されて（第１のステップ）、エラーの回数が所定回数に達すると、システムが異常状態であると判定されて当該コントロールユニットの通信が一旦中止される（第２のステップ）。
【００１３】
その後、通信を中止してから所定時間経過後に当該コントロールユニットの通信を試み（第３のステップ）、この通信時にエラーが生じたか否かが判定される（第４のステップ）。そして、通信エラーが生じていないと判定されると、システムが正常に復帰したものとして通常の通信が再開される。
また、請求項２にかかる本発明の車両用ネットワークの通信復帰判定方法では、第４のステップで通信エラーが生じたと判定されると、通信エラーが検出されなくなるまで第３のステップで所定時間毎に通信が行なわれる。
【００１４】
また、請求項３にかかる本発明の車両用ネットワークの通信復帰判定方法では、所定時間が、制御の重要度に応じて各コントロールユニットで個別に設定されており、重要度の高いコントロールユニットでは、所定時間が短く設定されている。
なお、第２のステップでエラー回数が所定回数に達したことが判定されると、エラー回数の積算値をリセットするのが好ましい。そして、このように構成することにより、システムが正常に復帰したときにはエラー回数０から通信が再開される。
【００１５】
【発明の実施の形態】
以下、図面により、本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法について説明する。
まず最初に、ＣＡＮの仕様及びＳＡＥ  Ｊ１９３９で規定されている内容の概略について説明すると、図１はネットワークの全体構成の一例を示す図であり、複数のＥＣＵ１ａ〜１ｄがバスライン１０により接続されている。ここでは、例えば１ａはエンジン制御用ＥＣＵ、１ｂは自動変速機（ＡＴ）制御用ＥＣＵ、１ｃはＡＢＳ制御用ＥＣＵ、１ｄはＴＲＣ（トラクションコントロール）制御用ＥＣＵである。
【００１６】
また、通信データは、図２に示すような通信フレーム（データフレーム）で送受信されるようになっている。データフレームは、図示するように、調停フィールド，制御フィールド及びデータフィールド等を備えており、以下、順番に説明する。
１．データフレームの各構成要素の説明。
(1) ＳＯＦ（Start  Of  Frame）
これは、フレームの開始示す識別子であり、常に“０”である。
(2) ｉｄｅｎｔｉｆｅｒ
これは、標準フォーマットのＩＤであり、詳細については、後述する「２．１．調停フィールド」の項で説明する。
(3) ＳＲＲ（Substitute  Remote  Request）
後述する (4)のＩＤＥと組み合わせて標準フレームフォーマット又は拡張フレームフォーマットのいずれか一方を選択するためのビットである。
(4) ＩＤＥ（Identifier  Extension  bit）
拡張フレームフォーマットを使用することを示すビットであり、ＳＲＲビットが“１”で、ＩＤＥビットが“１”のときには拡張フレームフォーマットが、ＳＲＲビットが無しで、ＩＤＥビットが“０”のときには標準フレームフォーマットが選択されていること示す。
(5) ｉｄｅｎｔｉｆｅｒ  ｅｘｔ．
標準フレームフォーマットに対して拡張していることを示すＩＤである。詳細については、後述する「２．１．調停フィールド」の項で説明する。
(6) ＲＴＲ（Remote  Transmission  Request）
リモート送信の要求を示すビットである。なお、リモート送信とは、あるシステムへデータ送信を要求することをいい、このＲＴＲビットが“０”のときは通常送信（データフレーム送信時）、“１”のときはリモート送信（リモートフレーム送信時）であることを示す。
(7) Ｒ１，Ｒ０
将来のデータ長拡張のために予約されているビット（予約ビット）であり、現在はすべて“０”である。後述の(8)ＤＬＣビットと組み合わせてデータ長が拡張される予定になっている。
(8) ＤＬＣ（Data  Length  Code）
データフィールドのデータであり、バイト長を設定するためのビットである。
(9) Ｄａｔａ  Ｆｉｅｌｄ
送信データを格納するためのデータフィールドである。ＳＡＥ  Ｊ１９３９では、８バイトデータを推奨している。
(10)ＣＲＣ（Cyclic  Redundancy  Check）
送信データの誤りのチェックコード格納用フィールドである。
(11)ＣＲＣ  ｄｅｌｉｍｉｔｅｒ
ＣＲＣ区切り記号であり、常に“１”となっている。
(12)ＡＣＫ（Acknowledgement）
正常受信確認のためのフィールドであり、送信側は“１１”を格納する。受信側はＣＲＣフィールドでデータチェックした結果が正常であれば“０１”、異常がある場合には“１１”を格納する。
(13)ＥＯＦ（End  Of  Frame）
送信終了を示すフィールド（７ビット）であり、常に“１１１１１１１”となっている。
【００１７】
２．ＰＤＵ（プロトコルデータユニット）についての説明。
次に、図２中のＰＤＵについて説明すると、ＰＤＵはデータフレーム内の主要な情報であり、図２に示すような調停フィールドの (2)ｉｄｅｎｔｉｆｅｒ， (5)ｉｄｅｎｔｉｆｅｒ  ｅｘｔ．及び (9)Ｄａｔａ  Ｆｉｅｌｄにより構成されている。また、このデータからＰＧＮ（Parameter  Group  Number）が決定される。ここでＰＧＮはデータを識別するための番号であり、調停フィールド（詳細は下記の２．１．調停フィールドの説明を参照）のＲ（予備），ＤＰ（データページ）及びＰＦ（ＰＤＵフォーマット）等から構成されている（データ長３バイト）。
【００１８】
２．１．調停フィールド
調停フィールドは、２９ｂｉｔのＩＤと３ｂｉｔのコントロールビットとから構成される。図３に調停フィールドの概略を示す。以下、調停フィールドの各部について説明する。
(1) 優先度
メッセージの優先順位を決めるために用いられ、“０００”が最も優先順位が高く、“１１１”が最も優先順位が低い。
(2) 予備
ＳＡＥが将来の機能拡張用として予約しているビット。現在は未使用のため“０”とする。
(3) データページ
ＰＤＵのページは２つあり、そのページのセレクタとして使用する。ページ０から使用する。
(4) ＰＤＵフォーマット（ＰＦ）
ＰＤＵ  Ｓｐｅｃｉｆｉｃ〔(7)参照〕の内容を決めるパラメータであり、ＰＧＮを構成する１つのフィールドである。
(5) ＳＲＲ
「１．データフレームの各構成要素の説明」の項目(3) 参照。
(6) ＩＤＥ
「１．データフレームの各構成要素の説明」の項目(4) 参照。
(7) ＰＤＵ  Ｓｐｅｃｉｆｉｃ（ＰＳ）
ＰＦの値により、ＰＳは送信先アドレス（ＤＡ）かグループ拡張（ＧＥ）のどちらか一方となる。
(8) ソースアドレス
メッセージの送信元アドレスが記述される。各システムのアドレスはＳＡＥ  Ｊ１９３９で規定されている。
【００１９】
２．２．制御フィールド
制御フィールドは、図４に示すように、予約ビット（２ｂｉｔ）とＤＬＣ（４ｂｉｔ）とから構成される。
２．３．データフィールド
送信データを格納するためのフィールドであり、ＳＡＥ  Ｊ１９３９ではデータ長８バイト固定を推奨している。
【００２０】
次に、ＥＣＵ１ａ〜１ｄでの通信エラー判定について説明すると、各ＥＣＵ１ａ〜１ｄには、それぞれ図５に示すようなデータ入出力部（ＣＡＮ  Ｉ／Ｏ）２が設けられている。このデータ入出力部２は、データ送信回路３，異常検知回路４及びデータ送信回路５等をそなえて構成されており、ＣＰＵ６に接続されている。
【００２１】
そして、ＣＰＵ６からの送信データはデータ送信回路３を介して他のＥＣＵに送信されるとともに、このときのＡＣＫフィールドのビット“１１”がバス異常検知回路４に取り込まれるようになっている。
また、データを送信した際には、相手のＥＣＵから送信したデータが返ってくるが、このとき肯定応答の有無によりエラーの発生が判定されるようになっている。つまり、上述したように、受信側のＥＣＵでは、受信データが正常であればＡＣＫフィールドのビットを“０１”、異常であれば“１１”として返信するとともに、この返信信号はバス異常検知回路４にも取り込まれようになっており、異常検知回路４では、これらのＡＣＫのビットをモニタすることで通信エラーが発生したか否かを判定できるようになっている。
【００２２】
なお、図５に示すように、ＣＡＮでは、ＨとＬとの２つの信号でデータがやり取りされるようになっている。ＨとＬとでは、例えばデータは図７（ａ），（ｂ）に示すように、正負が逆で対称の形状の信号となっており、これらの信号の差（ＣＡＮ  Ｈ−ＣＡＮ  Ｌ）がＣＰＵ６に入力されるようになっている。これにより、図７（ｂ）に示すように、信号にノイズが侵入しても、ノイズが相殺されるようになっている。
【００２３】
そして、本発明にかかる車両用ネットワークの通信復帰判定方法では、図６に示すようなフローチャートによりエラー発生時の処理が実行されるようになっている。なお、このような処理は個々のＥＣＵ１ａ〜１ｄ毎に実行されるものであり、以下、任意のＥＣＵに着目して説明する。
まず、ステップＳ１でＣＡＮ通信が実行され、通信エラーが検出されるとステップＳ２で通信エラー（ＣＡＮバスエラー）の検出回数がカウントされる（第１のステップ）。
【００２４】
そして、通信エラーが所定回数（２５６回）に達するまでは、従来と同様にステップＳ１に戻って通信が続行され、通信エラーのカウント値が２５６になるとステップＳ３に進んで、一旦当該ＥＣＵの通信が中止される（第２のステップ）。
その後、ステップＳ４でエラー回数がリセットされるとともに、ステップＳ５で、所定時間（例えば、１００ｍｓ）経過後に１回だけＣＡＮ通信が実行される（第３のステップ）。そして、ステップＳ６では、この通信時に、通信エラーが検出されたか否か（このときは１回のエラー検出）を判定して（第４のステップ）、通信エラーが検出された場合には上述したステップＳ４に戻り、その後ステップＳ４〜Ｓ６のエラーモード処理（エラーリセット，所定時間後の通信再開及びエラーの判定）が繰り返される。つまり、この場合には、正常に通信が行なわれるまで、上記所定時間毎にＣＡＮ通信を試みるのである。
【００２５】
一方、ステップＳ６で、エラーが検出されなかった場合には、通信システムの異常状態が正常状態に復帰したものとしてステップＳ１に戻り、通常の通信を再開するのである。
なお、上記の所定時間は、制御の重要度に応じて各ＥＣＵで異なる値に設定してもよい。例えば、早期に異常状態から復帰しないと車両の走行に支障をきたすようなシステム（エンジン，ＡＴ及びブレーキ制御等にかかるシステム）では、所定時間を１００ｍｓとし、又、異常状態からの復帰が多少遅れても走行に対して影響の少ないシステム（トラクションコントロールや補助ブレーキ等のシステム）では、５００ｍｓ程度に設定することが考えられる。また、エラーのままでも走行に問題のないシステム（例えばオートクルーズにかかるシステム）では、所定時間を∞に設定して、次回のキーオン（電源オン）まで復帰判定をしないようにしてもよい。そして、このように設定することにより、複数のＥＣＵが接触不良等により同時にエラーが生じた際には制御上重要なＥＣＵの方を優先して復旧させることができるのである。
【００２６】
このように、本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法によれば、ＣＡＮバスの接触不良等の一時的な異常時に、他の正常なＥＣＵに影響を与えることなくシステムの正常状態への復帰を判定することができる利点がある。
また、ステップＳ６の通信時に、通信エラーが検出された場合には、正常に通信が行なわれるまで、上記所定時間毎にエラーモードの処理（ステップＳ４〜Ｓ６）が繰り返されるので、システムの正常状態への復帰を確実に判定することができるという利点がある。
【００２７】
さらに、ステップＳ２で通信エラーのカウント値が所定値（２５６）に達すると、ステップＳ４で上記エラー回数の積算値がリセットされるので、システムの正常復帰時にはエラー回数が０となり、次回の通信エラー判定にそなえることができる利点がある。
なお、本発明の実施形態は上述のものに限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々の変更が可能である。例えば、上述では、ネットワークが、コントロールエリアネットワーク（ＣＡＮ）として構築されている例を示したが、これ以外にも複数のＥＣＵを通信線（バスライン）で接続し、相互にデータ通信を行なうネットワークに広く適用することができる。
【００２８】
【発明の効果】
以上詳述したように、請求項１にかかる本発明の車両用ネットワークの通信復帰判定方法によれば、任意のコントロールユニットにおいて通信エラーが検出されて通信が中止されてから所定時間経過後に当該コントロールユニットの通信を試み、この通信時に通信エラーが生じていないと判定されると、システムが正常に復帰したものとして通常の通信が再開されるので、接触不良等の一時的な異常時に、他の正常なコントロールユニットに影響を与えることなくシステムの正常状態への復帰を判定することができる利点がある。
【００２９】
また、請求項２にかかる本発明の車両用ネットワークの通信復帰判定方法によれば、通信が中止されてから所定時間経過後に当該コントロールユニットの通信を試みた際に通信エラーが生じると、通信エラーが検出されなくなるまで上記所定時間毎に通信が行なわれるので、請求項１の利点に加えて、確実にシステムの復旧を判定することができる利点がある。
【００３０】
また、請求項３にかかる本発明の車両用ネットワークの通信復帰判定方法によれば、上記の所定時間を制御の重要度に応じて各コントロールユニットで個別に設定することにより、接触不良等により複数のコントロールユニットに同時にエラーが生じた際には、制御上重要なコントロールユニットを優先して復旧させることができるという利点がある。
【図面の簡単な説明】
【図１】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用さされるシステムの全体構成を示す図である。
【図２】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用されるシステムのデータ形式について説明するための図である。
【図３】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用されるシステムのデータ形式について説明するための図である。
【図４】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用されるシステムのデータ形式について説明するための図である。
【図５】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用されるコントロールユニットの要部構成を示す模式図である。
【図６】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法の要部を説明するためのフローチャートである。
【図７】本発明の一実施形態にかかる車両用ネットワークの通信復帰判定方法が適用されるシステムのデータ送受信方法を説明するための図である。
【図８】（ａ），（ｂ）はともに本発明の創案過程で案出された通信復帰判定方法を説明するためのフローチャートである。
【符号の説明】
１ａ〜１ｄ  ＥＣＵ（コントロールユニット）
２  データ入出力部（ＣＡＮ  Ｉ／Ｏ）
３  データ送信回路
４  異常検知回路
５  データ送信回路
６  ＣＰＵ
【図１】
0003770053.tif 000002
【図２】
0003770053.tif 000003
【図３】
0003770053.tif 000004
【図４】
0003770053.tif 000005
【図５】
0003770053.tif 000006
【図６】
0003770053.tif 000007
【図７】
0003770053.tif 000008
【図８】
0003770053.tif 000009