車両用通信中継装置、スリープ制御方法
【課題】付け捨て端子がある場合でも早期にスリープモードに入れる車両用通信中継装置を提供すること。
【解決手段】複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置１００であって、端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段２３と、端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段２５と、送信異常の回数が第１の閾値以上になった場合に端末ごとに設けられたカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、カウンタフラグに所定値を設定するフラグ処理手段２２と、前記カウンタフラグが前記所定値以上の第２の閾値になった場合、端子に接続された端末のスリープ条件が成立したと判定するスリープ制御手段２１と、を有することを特徴とする。
【解決手段】複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置１００であって、端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段２３と、端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段２５と、送信異常の回数が第１の閾値以上になった場合に端末ごとに設けられたカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、カウンタフラグに所定値を設定するフラグ処理手段２２と、前記カウンタフラグが前記所定値以上の第２の閾値になった場合、端子に接続された端末のスリープ条件が成立したと判定するスリープ制御手段２１と、を有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置等に関する。
【背景技術】
【０００２】
車両には、エンジン、パワーステアリング、ボディ系などの車載装置を制御するための多くのＥＣＵ（Electronic Control Unit）が搭載されている。各ＥＣＵはネットワークを介して接続されており、一方のＥＣＵが他方のＥＣＵの通信データを利用することなどにより、車載装置の高度な制御を実現している。
【０００３】
車載されるＥＣＵの数が多くなると、ネットワーク上を通信データが輻輳して送信の遅延が生じやすくなるため、ゲートウェイ装置を配置することでネットワークをいくつかの車載ＬＡＮに分割することがしばしば行われる。また、ゲートウェイ装置は、エンジンやトランスミッション、ブレーキなどを制御するＥＣＵが接続された制御系の車載ＬＡＮ、ドアロック、パワーウインドウ、エアコンなどを制御するＥＣＵが接続されたボディ系、オーディオ、ナビなどを制御するＥＣＵが接続された情報系など、異なる車載ＬＡＮの境界に配置されることも多い。
【０００４】
ゲートウェイ装置は複数のチャネル（端子）を有し、チャネル毎に１つの車載ＬＡＮを接続する。ゲートウェイ装置は、通信プロトコルの違いを吸収したり、通信速度の違いを吸収して、あるチャネルから他方のチャネルに転送する通信データを取捨する制御等を行う。また、ゲートウェイ装置は、チャネルに接続されているＥＣＵが通信データを受信可能か否か判定するため、各ＥＣＵの異常の有無を判定することがある（例えば、特許文献１参照。）。特許文献１には、定期的に送信されるメッセージを受信バッファが受信した回数をカウントし、受信バッファが受信すべきメッセージの受信回数である判定値と比較することによりＥＣＵの異常を検出するゲートウェイ装置が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２８７７３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、各ＥＣＵは、ＩＧ−ＯＮの間、常に動作しているとは限らず、処理が終了してから所定時間が経過するとスリープモードに入るなどの省エネ機能を搭載している。しかしながら、複数のＥＣＵがゲートウェイ装置を介して接続されている場合、あるＥＣＵがスリープモードに入れるとしても、他のＥＣＵは処理を継続している可能性があり、あるＥＣＵがスリープモードに入った後に他のＥＣＵが通信データを送信しても、スリープモードに入ったＥＣＵが受信できない状況が生じてしまう。そこで、ゲートウェイ装置は、全てのチャネルに接続されたＥＣＵ（又は予め決められたＥＣＵ）がスリープモードに入れる場合に各ＥＣＵにスリープモードに入ることを許可する。このようなスリープ制御をバス間協調スリープ制御という。
【０００７】
しかしながら、各ＥＣＵが正常であれば、ゲートウェイ装置にスリープモードへの移行要求を送信することができるが、通信ができないなどの異常のあるＥＣＵはゲートウェイ装置にスリープモードへの移行要求を送信することができない。同様のことがチャネルから車載ＬＡＮのケーブルが外れた場合にも発生する。このような場合、異常のあるＥＣＵやチャネルのために、他の全てのチャネルに接続された全てのＥＣＵがスリープモードに入れないという不都合を生じる。
【０００８】
そこで、ゲートウェイ装置は、ＥＣＵの通信異常を判断することで、異常のあるＥＣＵからスリープモードへの移行要求を受信できなくても、バス間協調スリープ制御を可能にしている。具体的には、ゲートウェイ装置は、定期的に各ＥＣＵの通信データを受信し、そのフレームの受信有無を判定することで、ＥＣＵの異常を検出している。ＥＣＵに異常であることが検出されれば、そのＥＣＵからスリープモードへの移行要求がなくても、各ＥＣＵにスリープモードに入ることを許可できる。しかしながら、通信データを受信できない異常の場合、ゲートウェイのスリープに時間がかかる（タイムアウトまで待機するため）。
【０００９】
ここで、ゲートウェイ装置から見てＥＣＵの異常やケーブルの断線と似た現象をもたらす状況として、端子の付け捨てがある。
【００１０】
図１は、端子の付け捨ての一例を示す図である。端子の付け捨てとは、ゲートウェイ装置の複数のチャネル（図では３つ）のうち、予備のチャネル（図ではCH３）であるため車両の出荷時にＥＣＵが接続されないことをいう。ゲートウェイ装置から見ると、ＥＣＵに通信異常や断線が生じた場合は、スリープモードに入るまでに時間がかかる。このため、付け捨ての端子があるゲートウェイ装置に接続された全てのチャネルの全てのＥＣＵは、通信異常や断線が生じたと判定されるまで、スリープモードに入れないという問題がある。
【００１１】
ＥＣＵがスリープモードに移行する度に、付け捨て端子のＥＣＵ（実際には存在しない）や付け捨て端子に通信異常が生じていると判定されるまで時間を費やしてしまう。この間は全てのＥＣＵが作動しているので、消費電力も無駄に使用されてしまう。
【００１２】
本発明は、上記課題に鑑み、付け捨て端子がある場合でも早期にスリープモードに入れる車両用通信中継装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置であって、端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段と、端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段と、送信異常の回数が第１の閾値（例えば、１００回）以上になった場合に端子毎に設けられたカウンタフラグ（例えば停止フラグ）を１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値（例えば２）を設定するフラグ処理手段と、前記カウンタフラグが前記所定値以上の第２の閾値（例えば３）になった場合、端子に接続された端末のスリープ条件が成立したと判定するスリープ制御手段と、を有することを特徴とする。
【発明の効果】
【００１４】
付け捨て端子がある場合でも早期にスリープモードに入れる車両用通信中継装置を提供することができる。
【図面の簡単な説明】
【００１５】
【図１】端子の付け捨ての一例を示す図である。
【図２】本実施形態のゲートウェイ装置の概略的な特徴の一例を示す図である。
【図３】車両のネットワークの概略構成図の一例である。
【図４】ゲートウェイ装置のハードウェア構成図の一例である。
【図５】ゲートウェイ装置の機能ブロック図の一例である。
【図６】スリープ制御部がバス間協調スリープ制御する手順を示すフローチャート図の一例である。
【図７】付け捨てか断線かを判別することなく、ゲートウェイ装置が停止フラグを操作する従来の手順を示すフローチャート図の一例である。
【図８】送信処理の手順を示すフローチャート図の一例である。
【図９】付け捨て端子に対応して、停止フラグ操作部が停止フラグを操作する手順を示すフローチャート図の一例である。
【図１０】端子３に対し、ゲートウェイ装置が送信停止するまでの時間を模式的に説明する図の一例である。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を参照しながら説明する。
〔概略例〕
図２は、本実施形態のゲートウェイ装置１００の概略的な特徴の一例を示す図である。図２のゲートウェイ装置１００は３つの端子（チャネル）を有しており、端子３は車載ＬＡＮに接続されない付け捨て端子である。
（１）ゲートウェイ装置１００は各端子１〜３毎に送信及び受信が可能か否かを判定している。端子１，２については送信及び受信が可能であるが、端子３から送信及び受信することができない。
（２）ゲートウェイ装置１００は、送信回数をカウントして無応答の回数が閾値以上になると端子３に異常があると判定する。ゲートウェイ装置１００は端子３に異常があると判定すると、他の端子１，２の状況に応じて車載ＬＡＮ１，２のＥＣＵがスリープモードに入ることを許可できる。ここまでは従来と同様になる。
（３）ところで、ゲートウェイ装置１００は、通信データを転送するため端子に接続しているＥＣＵを管理している。したがって、過去に一度でも、ゲートウェイ装置１００と正常に通信したＥＣＵは端子と対応づけて受信情報が残っている。受信情報は、例えば各ＥＣＵのＣＡＮ ＩＤである。したがって、端子１，２には受信情報があるが、付け捨てである端子３には受信記録がない。本実施形態のゲートウェイ装置１００はこのことを利用して、付け捨て端子があっても早期にスリープモードに入ることを可能とする。
【００１７】
このため、ゲートウェイ装置１００は、端子３に受信情報があるか否かを判定する。受信情報がない場合、端子が断線していることを示す停止フラグに、送信回数のカウントを省略可能な値（図では２）を設定する。停止フラグにこのような値が設定されることで、送信を繰り返す時間を短縮でき、早期にスリープモードに入ることが可能になる。
（４）また、ゲートウェイ装置１００は、閾値以上になったカウンタ値（送信回数）をＲＡＭ１３などに記憶しておく（ＲＡＭ１３にはバッテリから電力が供給されるのでカウンタ値は消去されない）。
（５）したがって、次回の端子１，２のＥＣＵがウェイクアップした場合、ゲートウェイ装置１００はＲＡＭ１３に記憶されたカウンタ値を初期値として、閾値以上か否かを判定する。端子３の停止フラグには、上記と同様に、送信回数のカウントを省略可能な値（図では２）が設定される。カウンタ値はすでに閾値以上なので、ゲートウェイ装置１００はほとんど時間を費やすことなく、端子３は異常があると判定し、早期にスリープモードに入ることが可能になる。
【００１８】
このように、本実施形態のゲートウェイ装置１００は、出荷後（又はバッテリ装着後）の最初のウェイクアップ時だけ、閾値以上になるまで送信回数をカウントする必要があるが、その場合でも、停止フラグに適切な値を設定するので、従来よりも短い時間でバス間協調スリープが可能になる。
【００１９】
また、閾値以上になったカウンタ値を記憶しておくので、一度だけカウンタ値を閾値以上までカウントしておけば、次回からは、停止フラグに送信回数のカウントを省略可能な値（上記の２）を設定することも作用して、ウェイクアップ時にすぐにスリープモードに入ることができる。
【００２０】
また、端子１，２については、断線などが生じても受信記録があるため、停止フラグに送信回数のカウントを省略可能な値は設定されない。このため、付け捨てでない端子１，２については、従来どおり、送信回数が閾値以上になるまでカウントして、異常の有無を判定することができる。
【００２１】
〔構成例〕
図３は、車載システム２００の概略構成図の一例を示す。ゲートウェイ装置１００には、車載ＬＡＮ１と車載ＬＡＮ２が接続されており、車載ＬＡＮ１には１つ以上のＥＣＵ１１〜１ｎ（単にＥＣＵ１という）が、車載ＬＡＮ２には１つ以上のＥＣＵ２１〜２ｎ（単にＥＣＵ１という）が、それぞれ接続されている。ゲートウェイ装置１００は３つの端子を有し、端子１に車載ＬＡＮ１が、端子２に車載ＬＡＮ２がそれぞれ接続されているが、端子３は付け捨て端子である。端子の数は３つ以上であればよく、そのうち少なくとも１つが付け捨て端子であればよい。
【００２２】
車載システム２００は、ネットワークに接続されるＥＣＵ１，２を機能的又は場所的にグループに分けるために別々の車載ＬＡＮ１，２に分割されている。ネットワークをグループ分けすることで、１つの車載ＬＡＮに接続されている複数のＥＣＵの起動状態の管理やウェイクアップ制御、スリープ制御が容易になる。
【００２３】
車載ＬＡＮ１，２の通信プロトコルは、例えば、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、Ｆｌｅｘｒａｙ等であり、この他どのようなプロトコルを採用してもよい。本実施例では、ＣＡＮプロトコルを例にして説明する。
【００２４】
ゲートウェイ装置１００は、このように、複数の車載ＬＡＮ１，２の間で、異なる系統間の通信データを仲介したり、１つの車載ＬＡＮのケーブルの配線長や通信データの通信量がもたらす負荷を緩和する。
【００２５】
例えば、ゲートウェイ装置１００は、車載ＬＡＮ１から車載ＬＡＮ２に、車載ＬＡＮ２から車載ＬＡＮ１に通信データを中継する。ＥＣＵ１が送信する通信データは車載ＬＡＮ１を伝わってゲートウェイ装置１００に到達して受信バッファに記憶される。ＥＣＵ２が通信データを送信した場合も同様である。ゲートウェイ装置１００は、通信データのＣＡＮ ＩＤを参照してフィルタリングポリシーに従って、他方の車載ＬＡＮに中継するか否かを決定する。
【００２６】
例えば、ＣＡＮプロトコルの場合、次のようなデータフォーマット「ＳＯＦ；データＩＤフィールド；ＲＴＲ；制御フィールド；データフィールド；ＣＲＣフィールド；ＡＣＫフィールド；ＥＯＦ」を１フレームとして１つの通信データを送信する。データＩＤフィールドにはＥＣＵ１、ＥＣＵ２に固有のＩＤ（ＣＡＮ ＩＤ）が格納されており、ゲートウェイ装置１００や他のＥＣＵが通信データを識別するために使用される。フィルタリングポリシーでは、端子毎に転送すべき通信データのＩＤとその転送先の端子が登録されている。
【００２７】
ゲートウェイ装置１００は、ＥＣＵ１、ＥＣＵ２が後述する通常モードで動作中、定期的に通信確認を行うことでＥＣＵ１，２や車載ＬＡＮ１，２に異常があるか否か、及び、異常の内容等を検出している。ゲートウェイ装置１００が定期的に送信する通信データをステータス通知要求といい、ＥＣＵ１，２がステータス通知要求に応答して少なくともＡＣＫを送信し又は通信可能な異常があればその内容をゲートウェイ装置１００に送信する（以下、単にＥＣＵ１，２が返送する通信データを“ＡＣＫ”という）。ゲートウェイ装置１００はＥＣＵ１やＥＣＵ２からＡＣＫがない場合、ＥＣＵ１，２の通信異常や端子１，２の断線を検出する。
【００２８】
図４は、ゲートウェイ装置１００のハードウェア構成図の一例を示す。ゲートウェイ装置１００は、端子毎に搭載されたＣＡＮコントローラ１１、ＣＰＵ１２、ＲＯＭ１４及びＲＡＭ１３を有している。この他、ゲートウェイ装置１００が有しているフラッシュメモリ、タイマ、ＷＤＴ、Ｉ／Ｏ、ＩＣ等は省略している。ＣＰＵ１２はＲＯＭ１４に記憶されたプログラムを実行して、通信データの中継処理、バス間協調スリープ制御、ＥＣＵの通信異常や端子の断線判定等を行う。これらの処理の中で付け捨て端子が特定される。
【００２９】
ＣＡＮコントローラ１１は、車載ＬＡＮ１又は車載ＬＡＮ２から通信データを受信するとＣＰＵ１２に割り込むなどして受信したことを通知する。通信データは受信バッファ（ＲＡＭ１３の一領域にある）に記憶される。ＣＰＵ１２は、受信バッファに記憶されたデータフレームからＣＡＮ ＩＤを抽出して、フィルタリングポリシーと照らし合わせ、転送が必要か否かを判定する。ＣＰＵ１２は、転送が必要な通信データは送信バッファに記憶して、送信側のＣＡＮコントローラ１１に送信を要求する。送信側のＣＡＮコントローラ１１は、通信データの送信要求を受け付けると上記のようなフレームの各フィールドに、ＣＡＮ ＩＤ（この場合はゲートウェイのＣＡＮ ＩＤ）、データ等を格納し車載ＬＡＮ１，２に送信する。
【００３０】
このように、ゲートウェイ装置１００の端子１にはＥＣＵ１の通信データ、端子２にはＥＣＵ２の通信データが到達するので、ゲートウェイ装置１００は端子に対応づけて各ＥＣＵのＣＡＮ ＩＤを記憶しておく。このＣＡＮ ＩＤが受信情報である。こうすることで、端子１，２に接続されているＥＣＵ１，２を特定することができる（上記のような転送も可能になる）。以下、端子とＣＡＮ ＩＤの関係を登録したデータを端子受信テーブル２５という。
【００３１】
端子受信テーブル２５は例えばＲＡＭ１３に記憶される。ゲートウェイ装置１００にはバッテリから電力が供給されるので、ＩＧ−ＯＦＦしてもＲＡＭ１３のデータは消去されない。また、ＲＡＭ１３には、ＡＣＫを受信できなかったステータス通知要求の送信回数を端子毎に登録した送信回数テーブル２４、端子毎の停止フラグが登録された停止フラグテーブル２６が記録される。送信回数については後述する。
【００３２】
＜スリープモードについて＞
各ＥＣＵ１、２は、プログラムが動作可能な通常モードと対比して称されるスリープモード（又は省電力モード）で動作することができる。スリープモードは、例えば、ＣＰＵ１２の動作クロックが最小限に低減される状態、ＲＡＭ１３などの最小限のチップにしか電力が供給されない状態など、消費電力を抑制可能な動作モードである。説明のため、プログラムが動作可能なモードを通常モードと称す。よって、スリープモード以外の動作モードが通常モードである。なお、動作クロックが数段階に低減されたり、段階的に電力を供給するチップ数を低減するなど、スリープモードにいくつかの段階があってもよい。
【００３３】
通常モードからスリープモードへの移行条件は、ＥＣＵ毎に様々であるが、例えば、乗員がＩＧオフに操作したこと、ＩＧオフ後、定められた終了処理（アクチュエータを安全に停止させる処理、ＥＣＵハードのアクセスを適切に終了させる処理等）が終了したこと、監視対象の通信線の所定時間の平均電圧が閾値未満であったこと（つまりそのＥＣＵが使用されていない）、等である。
【００３４】
スリープモードから通常モードへの移行条件もＥＣＵ１００によって様々であるが、例えば、乗員がＩＧオンに操作したこと（ハイブリッド車や電気自動車の場合はメインシステムをオンに操作すること）、監視対象の通信線の所定時間の平均電圧が閾値以上であったこと、ユーザ操作が検出されたこと等である。例えば、ＩＧ−ＯＮの場合は、ＥＣＵ（マイコン、又は、ＣＰＵ１２でもよい）及びゲートウェイ装置１００のＷＡＫＥ端子にウェイクアップ信号が入力されることで検出される。スリープモードから通常モードへ移行することをウェイクアップという。
【００３５】
〔ゲートウェイ装置の機能〕
図５は、ゲートウェイ装置１００の機能ブロック図の一例である。ゲートウェイ装置１００は、スリープ制御部２１、停止フラグ操作部２２及び送信処理部２３を有する。スリープ制御部２１は車載ＬＡＮの全てのＥＣＵ１，２がスリープ可能か否かを判断して、バス間協調スリープ制御を行う。送信処理部２３は、ステータス通知要求をＥＣＵ１，２に送信して、ＡＣＫを受信できない回数をカウントする。停止フラグ操作部２２は、送信回数が閾値以上になると停止フラグを１つ大きくする。これにより、ＥＣＵの通信異常若しくは断線、又は、付け捨て端子である場合に停止フラグが大きくなる。また、停止フラグ操作部２２は、受信端子テーブル２５を参照して、ＥＣＵが登録されていない端子の停止フラグに“２”を設定する。
【００３６】
例えば、図の端子受信テーブル２５には、端子１にＥＣＵ１が、端子２にＥＣＵ２が、接続されていること（過去にＥＣＵ１、２から端子１，２に通信データが送信されたこと）が登録されている。また、端子３は付け捨て端子なので、端子３にはＥＣＵが登録されていない。端子受信テーブル２５のＥＣＵ１，２は例えば、ＣＡＮ ＩＤ（図１の受信情報に相当）であるが、過去に受信があったことを記録できればどのような情報でもよい。
【００３７】
＜バス間協調スリープ制御＞
図６を用いて、バス間協調スリープ制御について説明する。図６は、スリープ制御部２１がバス間協調スリープ制御する手順を示すフローチャート図の一例である。図６の処理は、各ＥＣＵがウェイクアップすることで開始され、ゲートウェイ装置１００が各ＥＣＵ１，２にスリープを許可するまでは繰り返し実行される。
【００３８】
まず、スリープ制御部２１はＥＣＵ１，２からスリープ要求があるか否かを判定する（Ｓ１）。
【００３９】
スリープ要求がある場合（Ｓ１のＹｅｓ）、スリープ制御部２１はスリープ要求したＥＣＵ１，２の識別情報（例えば、ＣＡＮ ＩＤ）を登録しておく（Ｓ２）。
【００４０】
スリープ要求したＥＣＵ１，２を登録すると、スリープ制御部２１は車載ＬＡＮ１，２に接続された全てのＥＣＵからスリープ要求があったか否かを判定する（Ｓ３）。すなわち、スリープ制御部２１は端子受信テーブル２５に登録されている全てのＥＣＵ１，２からスリープ要求があったか否かを判定する。
【００４１】
全てのＥＣＵ１，２からスリープ要求があった場合（Ｓ３のＹｅｓ）、スリープしているＥＣＵ１，２に通信データが送信される可能性がないため、スリープ制御部２１は全てのＥＣＵ１，２にスリープを許可する（Ｓ１００）。
【００４２】
全てのＥＣＵ１，２からスリープ要求がない場合（Ｓ３のＮｏ）、通信異常、端子とケーブルの断線、又は、付け捨て端子の可能性があるため、スリープ制御部２１はスリープ要求のないＥＣＵが接続された端子の停止フラグが“３”か否か判定する（Ｓ４）。停止フラグについては後述するが、停止フラグが“３”であるとはその端子とケーブルが断線しているか又は付け捨て端子であることを意味する。
【００４３】
スリープ要求のないＥＣＵが接続された端子の停止フラグが“３”である場合（Ｓ４のＹｅｓ）、スリープ制御部２１は、スリープ制御部２１は全てのＥＣＵにスリープを許可する（Ｓ１００）。
【００４４】
本実施形態では、停止フラグのカウント方法に特徴があり、付け捨て端子については早期にそれを検出し、断線の可能性のある端子については断線の有無を十分に判定することができる。
【００４５】
＜従来の停止フラグの操作＞
図７は、付け捨てか断線かを判別することなく、ゲートウェイ装置１００が停止フラグを操作する従来の手順を示すフローチャート図の一例である。
【００４６】
まず、スリープ制御部２１は各ＥＣＵ及びゲートウェイ装置１００がウェイクアップしたことを検出して、停止フラグをリセットする（Ｓ１０）。停止フラグはウェイクアップ毎に初期化され、その初期値はゼロとする。
【００４７】
バス間協調スリープ制御に至るまで、停止フラグ操作部２２はステータス通知要求の送信処理を繰り返す。すなわち、スリープ制御部２１はサイクル時間が経過したか否かを判定し（Ｓ２０）、サイクル時間が経過する毎に（Ｓ１２のＹｅｓ）、停止フラグ操作部２２は送信回数が閾値以上か否かを判定する（Ｓ３０）。この閾値は上記と同じ例えば“１００”回などであり、断線していると確定してよいか否かが判定されている。
【００４８】
送信回数が閾値以上の場合（Ｓ３０のＹｅｓ）、停止フラグ操作部２２は停止フラグを１つインクリメントする（Ｓ４０）。このように、停止フラグは送信回数が閾値以上になると１つ増えるフラグである。
【００４９】
次に、送信処理部２３に送信処理を要求する（Ｓ５０）。送信処理は、例えばＳ１２のタイマ割込みにより実行されるサブルーチン、メイン関数から呼びだされる関数などである。
【００５０】
これにより、送信処理部２３は定期的に送信処理を行うことができる。
図８は、送信処理の手順を示すフローチャート図の一例である。送信処理部２３は、各ＥＣＵ１，２にステータス通知要求を送信する（Ｓ３０１）。ステータス通知要求を送信すべきＥＣＵ１，２は端子受信テーブル２５に登録されている。または、全ての端子１，２から同報的にステータス通知要求を送信してもよい。
【００５１】
送信処理部２３はＡＣＫを受信したか否かを判定する（Ｓ３０２）。特定のＥＣＵに不具合が生じた場合、特定のＥＣＵのみからＡＣＫが受信できない状況が生じるが、本実施例では、端子１又は端子２から車載ＬＡＮのケーブルが外れているような場合を想定する。特定のＥＣＵの不具合が検出された場合、該ＥＣＵをリセットするなど所定の処理を行う。
【００５２】
端子１のＥＣＵから１つでもＡＣＫを受信した場合、及び、端子２のＥＣＵから１つでもＡＣＫを受信した場合（Ｓ３０２のＹｅｓ）、端子１，２に断線が生じておらず正常に通信可能であることになる。
【００５３】
端子１又は端子２から全くＡＣＫを受信しない場合（Ｓ３０２のＮｏ）、送信処理部２３は端子毎に送信回数をインクリメントする（Ｓ３０３）。送信回数は、ＲＡＭに記憶されている値が初期値であり、ステータス通知要求を送信してＡＣＫが受信されない毎に１つずつ大きくなる。したがって、送信回数が大きいことは断線の可能性が高いことを意味する。
【００５４】
次に、送信処理部２３は停止フラグが２以上か否かを判定する（Ｓ３０４）。停止フラグは断線していると判定してスリープモードに移行するか否かを判定するためのフラグである。閾値である“２”は一例であって、適宜設計できる。
【００５５】
停止フラグが２以上である場合（Ｓ３０４のＹｅｓ）、断線しているためスリープモードに移行すべきなので、送信処理部２３は何もしない。これにより、図７の手順で断線時のスリープモード移行制御が可能になる。
【００５６】
停止フラグが２以上でない場合（Ｓ３０４のＮｏ）、送信処理部２３は送信回数が“閾値＋１”以上か否かを判定する（Ｓ３０５）。この閾値は、断線していると判定してよい程度の数であり例えば“１００”回などである。より具体的には、車両の出荷後又はバッテリ装着後、最初のカウント時だけ合計２回、送信処理部２３は送信回数が閾値以上になるまでカウントする。一度、停止フラグが２以上になると、１回だけ、送信処理部２３は送信回数が閾値以上になるまでカウントする。
【００５７】
このため、送信処理部２３は端子毎にカウントした送信回数をリセットする（Ｓ３０６）。リセットとはゼロに戻すこという。送信回数がリセットされることで、送信処理部２３は、再度、閾値までカウントされるのでＳ３０１〜Ｓ３０３の処理が行われ、断線していなければ、この間にＡＣＫがあることが期待できる。
【００５８】
このように図８では、停止フラグが２以上の場合はステップＳ３０６で送信回数がリセットされず、停止フラグが２以上でない場合にだけ（送信回数が閾値＋１である場合）送信回数がリセットされる。停止フラグが２以上になる時は、必ず送信回数が閾値以上になっている（Ｓ４０のＹｅｓにより）。したがって、停止フラグが２以上になった端子の送信回数は閾値のままＲＡＭ１３に記憶されている。また、次回は、閾値の送信回数が初期値となる。
【００５９】
図７に戻り、停止フラグ操作部２２は、停止フラグが”３”か否かを判定する（Ｓ６０）。停止フラグが３以上であることは、送信回数が２回（出荷後又はバッテリ装着後の初回だけが２回で、それ以降は１回）、閾値以上となったことを意味し、その端子は完全に断線していると判断される判断基準である。
【００６０】
停止フラグが”３”の場合（Ｓ６０のＹｅｓ）、スリープ制御部２１は送信処理の呼び出しを禁止するなどして、その端子への送信処理を停止する（Ｓ７０）。この場合、断線の可能性があるので、ゲートウェイ装置１００は端子番号と通信異常を記録するなどして、後に解析可能としておく。
【００６１】
停止フラグが”３”でない場合（Ｓ６０のＮｏ）、停止フラグは２以下なので、停止フラグ操作部２２はステップＳ１０からの処理を繰り返す。ステップＳ５０の送信処理において、停止フラグが０，１であれば送信回数はリセットされるので、送信回数がゼロからカウントされる。
【００６２】
以上のような処理によれば、それまでゲートウェイ装置１００が正常に通信できていた端子なら、停止フラグが”３”以上になるまで、ＡＣＫの受信の有無を確認できるため好ましいと言える。一方、付け捨て端子がある場合、停止フラグが”３”以上になるまでスリープモードに入れないという不都合が生じる。
【００６３】
そこで、本実施形態のゲートウェイ装置１００は付け捨て端子には過去に通信データが到達していないことを利用して、早期に全てのＥＣＵがスリープモードに入ることを可能にする。
【００６４】
＜本実施形態の停止フラグの操作＞
図９は、付け捨て端子に対応して、停止フラグ操作部２２が停止フラグを操作する手順を示すフローチャート図の一例である。図９の手順において図７と同一部の処理は、簡単に説明する。
【００６５】
図９では、停止フラグをリセットすると、端子に受信履歴があるか否かを判定する（Ｓ１２）。停止フラグ操作部２２は端子受信テーブル２５を参照して、端子毎に１つ以上のＥＣＵが登録されているか否かを判定する。端子３のように付け捨て端子の場合、１つのＥＣＵも登録されていない。
【００６６】
端子３に受信履歴がない場合（Ｓ１２のＮｏ）、停止フラグ操作部２２は停止フラグを２つインクリメントする（Ｓ１４）。端子３に受信履歴がないということは、端子３は出荷時から付け捨てであったと判定してよい。よって、停止フラグを２つインクリメントすることで、送信回数が閾値を２回超えるまでに必要な時間を短縮できる。
【００６７】
端子１，２のように受信履歴がある場合（Ｓ１２のＹｅｓ）、停止フラグ操作部２２は停止フラグを操作しない（Ｓ１６）。よって、端子１，２のように出荷時にケーブルが接続されており、過去にＥＣＵ１，２が通信可能であった場合、従来と同様に、送信処理を行い断線の可能性を判定することができる。
【００６８】
以降の処理について、端子３を例に説明する。ステップＳ１４の処理により停止フラグは“２”になっている。
【００６９】
サイクル時間が経過すると（Ｓ２０のＹｅｓ）、ステップＳ３０では送信回数が閾値以上か否かが判定される。ここで、送信回数は閾値のままＲＡＭ１３に記憶されているが、車両の出荷後又はバッテリ装着後、端子３の送信回数が閾値以上になる処理が１度だけ必要になる。
【００７０】
よって、車両の出荷後又はバッテリ装着後、停止フラグが“２”のまま送信処理が実行される（Ｓ５０）。図８の送信処理では、停止フラグが“２”なので、送信回数はリセットされることなく、端子３の送信回数は閾値以上になるまでインクメントされる。
【００７１】
図９に戻り、送信回数が閾値以上になると（Ｓ３０のＹｅｓ）、停止フラグ操作部２２は停止フラグをインクリメントする（Ｓ４０）。これにより端子３に起因して停止フラグが“３”になる。図８の送信処理では停止フラグは変化しないので、ステップＳ６０の判定がＹｅｓとなり、端子３への送信処理が停止される（Ｓ７０）。
【００７２】
このように、図９のステップＳ１４により、ウェイクアップの後、すぐに停止フラグが“２”になるので、１度だけ送信回数が閾値以上になるまでカウントすれば、ゲートウェイ装置１００は送信処理を停止することができる。
【００７３】
これにより、バス間協調スリープ制御で説明したように、他の端子１，２の車載ＬＡＮに接続された各ＥＣＵがスリープ要求することで、ゲートウェイ装置１００は車載ＬＡＮ１，２に対し協調してスリープを許可することができる。
【００７４】
そして、車両の出荷後又はバッテリ装着後でない場合、送信回数はすでに閾値になっているので、最初のステップＳ３０でＹｅｓとなり、停止フラグは”３”となる（Ｓ４０）。その後、図８の送信処理から戻ると、ステップＳ６０の判定がＹｅｓとなり、端子３への送信処理が停止される（Ｓ７０）。
【００７５】
次回、ＥＣＵ１，２やゲートウェイ装置１００がＩＧ−ＯＮなどによりウェイクアップすると、ウェイクアップ後、ステップＳ１４で停止フラグは“２”になる。また、一度、閾値以上になった端子３の送信回数はＲＡＭ１３に記憶されているので、ステップＳ３０ではウェイクアップの直後に閾値以上になっている。これにより、停止フラグは“３”にインクリメントされ、ウェイクアップ後、すぐに送信処理が停止される（Ｓ７０）。
【００７６】
このように、付け捨て端子である端子３は、一度でも送信回数が閾値以上になると、ウェイクアップの直後から、スリープモードに入るための条件を満たす。したがって、ウェイクアップが２回目以降であれば、ゲートウェイ装置１００は、車載ＬＡＮ１，２のＥＣＵ１，２のスリープ要求しだいですぐにスリープを許可することができる。
【００７７】
〔効果の説明〕
図１０は、端子３に対し、ゲートウェイ装置１００が送信停止するまでの時間を模式的に説明する図の一例である。
（ａ）端子３が付け捨てか否かを判定しない場合
ゲートウェイ装置１００は端子３が付け捨てか否かを判定せず、断線している可能性を判定するため送信回数が２回、閾値（１００回）になるまで送信処理を行う。したがって、他の端子１，２のＥＣＵ１，２がスリープ要求していても、バス間協調スリープ制御が可能になるまでの時間が長くなる。
（ｂ）端子３が付け捨てか否かを判定する、出荷直後又はバッテリ装着直後の場合
出荷直後の端子３の送信回数はゼロとしてＲＡＭ１３に記憶されている。このため、停止フラグを３にするため、送信回数が１回だけ閾値になるまでカウントされる。したがって、従来よりも早期にＥＣＵ１，２の状態に応じてバス間協調スリープ制御が可能になる。なお、端子３の停止フラグは２以上なので、端子３の送信回数は閾値のままＲＡＭ１３に記憶される。
（ｃ）端子３が付け捨てか否かを判定する、出荷後又はバッテリ装着直後の２回目以降の場合
ウェイクアップの直後、端子３の送信回数はすでに閾値に達している。したがって、ゲートウェイ装置１００が１回送信を行うと（アルゴリズム上の処理であり１回も送信を行なわないようにすることも可能である）、停止フラグが３になる。したがって、ウェイクアップの直後、ほとんど時間を費やすことなく、端子３は、ＥＣＵ１，２の状態に応じてバス間協調スリープ制御が可能になる。
【００７８】
図７と９を比較すると明らかなように、従来のロジックと比較して修正点も少ないのでソフトウェア開発のコストも低減できる。
【００７９】
〔付け捨て端子にＥＣＵが接続された場合〕
車両の出荷時に付け捨てであった端子に、出荷後、ディーラーオプションの車載装置（例えば、盗難防止装置、リモートエンジン始動装置）やナビゲーション装置が接続される場合がある。この場合、本実施形態では、付け捨て端子に受信履歴が記録されていないため、装着後（ウェイクアップ後）、停止フラグがすぐに３になるおそれがある。
【００８０】
しかしながら、新しいＥＣＵが接続される場合、作業のため、車両からバッテリが取り外される。このため、ＲＡＭ１３にも電力が供給されなくなり、ＲＡＭ１３に記憶された端子３（端子１，２も）の送信回数はリセットされる。
【００８１】
送信回数がリセットされた場合、送信処理部２３は閾値（１００回）に達するまで送信処理を繰り返すので、その間に、新しいＥＣＵがゲートウェイ装置１００に対しＡＣＫを含む通信データを送信する。これにより、受信端子テーブル２５には端子３にＥＣＵから送信があったことが記録される。
【００８２】
したがって、出荷後に付け捨て端子にＥＣＵが接続されても、停止フラグに”２”が設定されることはなく、出荷時からＥＣＵが接続されている他の端子１，２と同様に、断線が判定されるようになる。
【符号の説明】
【００８３】
１１ ＣＡＮコントローラ
１２ ＣＰＵ
１３ ＲＡＭ
１４ ＲＯＭ
２１ スリープ制御部
２２ 停止フラグ操作部
２３ 送信処理部
２４ 送信回数テーブル
２５ 端子受信テーブル
２６ 停止フラグテーブル
１００ ゲートウェイ装置
２００ 車載システム
【技術分野】
【０００１】
本発明は、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置等に関する。
【背景技術】
【０００２】
車両には、エンジン、パワーステアリング、ボディ系などの車載装置を制御するための多くのＥＣＵ（Electronic Control Unit）が搭載されている。各ＥＣＵはネットワークを介して接続されており、一方のＥＣＵが他方のＥＣＵの通信データを利用することなどにより、車載装置の高度な制御を実現している。
【０００３】
車載されるＥＣＵの数が多くなると、ネットワーク上を通信データが輻輳して送信の遅延が生じやすくなるため、ゲートウェイ装置を配置することでネットワークをいくつかの車載ＬＡＮに分割することがしばしば行われる。また、ゲートウェイ装置は、エンジンやトランスミッション、ブレーキなどを制御するＥＣＵが接続された制御系の車載ＬＡＮ、ドアロック、パワーウインドウ、エアコンなどを制御するＥＣＵが接続されたボディ系、オーディオ、ナビなどを制御するＥＣＵが接続された情報系など、異なる車載ＬＡＮの境界に配置されることも多い。
【０００４】
ゲートウェイ装置は複数のチャネル（端子）を有し、チャネル毎に１つの車載ＬＡＮを接続する。ゲートウェイ装置は、通信プロトコルの違いを吸収したり、通信速度の違いを吸収して、あるチャネルから他方のチャネルに転送する通信データを取捨する制御等を行う。また、ゲートウェイ装置は、チャネルに接続されているＥＣＵが通信データを受信可能か否か判定するため、各ＥＣＵの異常の有無を判定することがある（例えば、特許文献１参照。）。特許文献１には、定期的に送信されるメッセージを受信バッファが受信した回数をカウントし、受信バッファが受信すべきメッセージの受信回数である判定値と比較することによりＥＣＵの異常を検出するゲートウェイ装置が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２８７７３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、各ＥＣＵは、ＩＧ−ＯＮの間、常に動作しているとは限らず、処理が終了してから所定時間が経過するとスリープモードに入るなどの省エネ機能を搭載している。しかしながら、複数のＥＣＵがゲートウェイ装置を介して接続されている場合、あるＥＣＵがスリープモードに入れるとしても、他のＥＣＵは処理を継続している可能性があり、あるＥＣＵがスリープモードに入った後に他のＥＣＵが通信データを送信しても、スリープモードに入ったＥＣＵが受信できない状況が生じてしまう。そこで、ゲートウェイ装置は、全てのチャネルに接続されたＥＣＵ（又は予め決められたＥＣＵ）がスリープモードに入れる場合に各ＥＣＵにスリープモードに入ることを許可する。このようなスリープ制御をバス間協調スリープ制御という。
【０００７】
しかしながら、各ＥＣＵが正常であれば、ゲートウェイ装置にスリープモードへの移行要求を送信することができるが、通信ができないなどの異常のあるＥＣＵはゲートウェイ装置にスリープモードへの移行要求を送信することができない。同様のことがチャネルから車載ＬＡＮのケーブルが外れた場合にも発生する。このような場合、異常のあるＥＣＵやチャネルのために、他の全てのチャネルに接続された全てのＥＣＵがスリープモードに入れないという不都合を生じる。
【０００８】
そこで、ゲートウェイ装置は、ＥＣＵの通信異常を判断することで、異常のあるＥＣＵからスリープモードへの移行要求を受信できなくても、バス間協調スリープ制御を可能にしている。具体的には、ゲートウェイ装置は、定期的に各ＥＣＵの通信データを受信し、そのフレームの受信有無を判定することで、ＥＣＵの異常を検出している。ＥＣＵに異常であることが検出されれば、そのＥＣＵからスリープモードへの移行要求がなくても、各ＥＣＵにスリープモードに入ることを許可できる。しかしながら、通信データを受信できない異常の場合、ゲートウェイのスリープに時間がかかる（タイムアウトまで待機するため）。
【０００９】
ここで、ゲートウェイ装置から見てＥＣＵの異常やケーブルの断線と似た現象をもたらす状況として、端子の付け捨てがある。
【００１０】
図１は、端子の付け捨ての一例を示す図である。端子の付け捨てとは、ゲートウェイ装置の複数のチャネル（図では３つ）のうち、予備のチャネル（図ではCH３）であるため車両の出荷時にＥＣＵが接続されないことをいう。ゲートウェイ装置から見ると、ＥＣＵに通信異常や断線が生じた場合は、スリープモードに入るまでに時間がかかる。このため、付け捨ての端子があるゲートウェイ装置に接続された全てのチャネルの全てのＥＣＵは、通信異常や断線が生じたと判定されるまで、スリープモードに入れないという問題がある。
【００１１】
ＥＣＵがスリープモードに移行する度に、付け捨て端子のＥＣＵ（実際には存在しない）や付け捨て端子に通信異常が生じていると判定されるまで時間を費やしてしまう。この間は全てのＥＣＵが作動しているので、消費電力も無駄に使用されてしまう。
【００１２】
本発明は、上記課題に鑑み、付け捨て端子がある場合でも早期にスリープモードに入れる車両用通信中継装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置であって、端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段と、端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段と、送信異常の回数が第１の閾値（例えば、１００回）以上になった場合に端子毎に設けられたカウンタフラグ（例えば停止フラグ）を１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値（例えば２）を設定するフラグ処理手段と、前記カウンタフラグが前記所定値以上の第２の閾値（例えば３）になった場合、端子に接続された端末のスリープ条件が成立したと判定するスリープ制御手段と、を有することを特徴とする。
【発明の効果】
【００１４】
付け捨て端子がある場合でも早期にスリープモードに入れる車両用通信中継装置を提供することができる。
【図面の簡単な説明】
【００１５】
【図１】端子の付け捨ての一例を示す図である。
【図２】本実施形態のゲートウェイ装置の概略的な特徴の一例を示す図である。
【図３】車両のネットワークの概略構成図の一例である。
【図４】ゲートウェイ装置のハードウェア構成図の一例である。
【図５】ゲートウェイ装置の機能ブロック図の一例である。
【図６】スリープ制御部がバス間協調スリープ制御する手順を示すフローチャート図の一例である。
【図７】付け捨てか断線かを判別することなく、ゲートウェイ装置が停止フラグを操作する従来の手順を示すフローチャート図の一例である。
【図８】送信処理の手順を示すフローチャート図の一例である。
【図９】付け捨て端子に対応して、停止フラグ操作部が停止フラグを操作する手順を示すフローチャート図の一例である。
【図１０】端子３に対し、ゲートウェイ装置が送信停止するまでの時間を模式的に説明する図の一例である。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を参照しながら説明する。
〔概略例〕
図２は、本実施形態のゲートウェイ装置１００の概略的な特徴の一例を示す図である。図２のゲートウェイ装置１００は３つの端子（チャネル）を有しており、端子３は車載ＬＡＮに接続されない付け捨て端子である。
（１）ゲートウェイ装置１００は各端子１〜３毎に送信及び受信が可能か否かを判定している。端子１，２については送信及び受信が可能であるが、端子３から送信及び受信することができない。
（２）ゲートウェイ装置１００は、送信回数をカウントして無応答の回数が閾値以上になると端子３に異常があると判定する。ゲートウェイ装置１００は端子３に異常があると判定すると、他の端子１，２の状況に応じて車載ＬＡＮ１，２のＥＣＵがスリープモードに入ることを許可できる。ここまでは従来と同様になる。
（３）ところで、ゲートウェイ装置１００は、通信データを転送するため端子に接続しているＥＣＵを管理している。したがって、過去に一度でも、ゲートウェイ装置１００と正常に通信したＥＣＵは端子と対応づけて受信情報が残っている。受信情報は、例えば各ＥＣＵのＣＡＮ ＩＤである。したがって、端子１，２には受信情報があるが、付け捨てである端子３には受信記録がない。本実施形態のゲートウェイ装置１００はこのことを利用して、付け捨て端子があっても早期にスリープモードに入ることを可能とする。
【００１７】
このため、ゲートウェイ装置１００は、端子３に受信情報があるか否かを判定する。受信情報がない場合、端子が断線していることを示す停止フラグに、送信回数のカウントを省略可能な値（図では２）を設定する。停止フラグにこのような値が設定されることで、送信を繰り返す時間を短縮でき、早期にスリープモードに入ることが可能になる。
（４）また、ゲートウェイ装置１００は、閾値以上になったカウンタ値（送信回数）をＲＡＭ１３などに記憶しておく（ＲＡＭ１３にはバッテリから電力が供給されるのでカウンタ値は消去されない）。
（５）したがって、次回の端子１，２のＥＣＵがウェイクアップした場合、ゲートウェイ装置１００はＲＡＭ１３に記憶されたカウンタ値を初期値として、閾値以上か否かを判定する。端子３の停止フラグには、上記と同様に、送信回数のカウントを省略可能な値（図では２）が設定される。カウンタ値はすでに閾値以上なので、ゲートウェイ装置１００はほとんど時間を費やすことなく、端子３は異常があると判定し、早期にスリープモードに入ることが可能になる。
【００１８】
このように、本実施形態のゲートウェイ装置１００は、出荷後（又はバッテリ装着後）の最初のウェイクアップ時だけ、閾値以上になるまで送信回数をカウントする必要があるが、その場合でも、停止フラグに適切な値を設定するので、従来よりも短い時間でバス間協調スリープが可能になる。
【００１９】
また、閾値以上になったカウンタ値を記憶しておくので、一度だけカウンタ値を閾値以上までカウントしておけば、次回からは、停止フラグに送信回数のカウントを省略可能な値（上記の２）を設定することも作用して、ウェイクアップ時にすぐにスリープモードに入ることができる。
【００２０】
また、端子１，２については、断線などが生じても受信記録があるため、停止フラグに送信回数のカウントを省略可能な値は設定されない。このため、付け捨てでない端子１，２については、従来どおり、送信回数が閾値以上になるまでカウントして、異常の有無を判定することができる。
【００２１】
〔構成例〕
図３は、車載システム２００の概略構成図の一例を示す。ゲートウェイ装置１００には、車載ＬＡＮ１と車載ＬＡＮ２が接続されており、車載ＬＡＮ１には１つ以上のＥＣＵ１１〜１ｎ（単にＥＣＵ１という）が、車載ＬＡＮ２には１つ以上のＥＣＵ２１〜２ｎ（単にＥＣＵ１という）が、それぞれ接続されている。ゲートウェイ装置１００は３つの端子を有し、端子１に車載ＬＡＮ１が、端子２に車載ＬＡＮ２がそれぞれ接続されているが、端子３は付け捨て端子である。端子の数は３つ以上であればよく、そのうち少なくとも１つが付け捨て端子であればよい。
【００２２】
車載システム２００は、ネットワークに接続されるＥＣＵ１，２を機能的又は場所的にグループに分けるために別々の車載ＬＡＮ１，２に分割されている。ネットワークをグループ分けすることで、１つの車載ＬＡＮに接続されている複数のＥＣＵの起動状態の管理やウェイクアップ制御、スリープ制御が容易になる。
【００２３】
車載ＬＡＮ１，２の通信プロトコルは、例えば、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、Ｆｌｅｘｒａｙ等であり、この他どのようなプロトコルを採用してもよい。本実施例では、ＣＡＮプロトコルを例にして説明する。
【００２４】
ゲートウェイ装置１００は、このように、複数の車載ＬＡＮ１，２の間で、異なる系統間の通信データを仲介したり、１つの車載ＬＡＮのケーブルの配線長や通信データの通信量がもたらす負荷を緩和する。
【００２５】
例えば、ゲートウェイ装置１００は、車載ＬＡＮ１から車載ＬＡＮ２に、車載ＬＡＮ２から車載ＬＡＮ１に通信データを中継する。ＥＣＵ１が送信する通信データは車載ＬＡＮ１を伝わってゲートウェイ装置１００に到達して受信バッファに記憶される。ＥＣＵ２が通信データを送信した場合も同様である。ゲートウェイ装置１００は、通信データのＣＡＮ ＩＤを参照してフィルタリングポリシーに従って、他方の車載ＬＡＮに中継するか否かを決定する。
【００２６】
例えば、ＣＡＮプロトコルの場合、次のようなデータフォーマット「ＳＯＦ；データＩＤフィールド；ＲＴＲ；制御フィールド；データフィールド；ＣＲＣフィールド；ＡＣＫフィールド；ＥＯＦ」を１フレームとして１つの通信データを送信する。データＩＤフィールドにはＥＣＵ１、ＥＣＵ２に固有のＩＤ（ＣＡＮ ＩＤ）が格納されており、ゲートウェイ装置１００や他のＥＣＵが通信データを識別するために使用される。フィルタリングポリシーでは、端子毎に転送すべき通信データのＩＤとその転送先の端子が登録されている。
【００２７】
ゲートウェイ装置１００は、ＥＣＵ１、ＥＣＵ２が後述する通常モードで動作中、定期的に通信確認を行うことでＥＣＵ１，２や車載ＬＡＮ１，２に異常があるか否か、及び、異常の内容等を検出している。ゲートウェイ装置１００が定期的に送信する通信データをステータス通知要求といい、ＥＣＵ１，２がステータス通知要求に応答して少なくともＡＣＫを送信し又は通信可能な異常があればその内容をゲートウェイ装置１００に送信する（以下、単にＥＣＵ１，２が返送する通信データを“ＡＣＫ”という）。ゲートウェイ装置１００はＥＣＵ１やＥＣＵ２からＡＣＫがない場合、ＥＣＵ１，２の通信異常や端子１，２の断線を検出する。
【００２８】
図４は、ゲートウェイ装置１００のハードウェア構成図の一例を示す。ゲートウェイ装置１００は、端子毎に搭載されたＣＡＮコントローラ１１、ＣＰＵ１２、ＲＯＭ１４及びＲＡＭ１３を有している。この他、ゲートウェイ装置１００が有しているフラッシュメモリ、タイマ、ＷＤＴ、Ｉ／Ｏ、ＩＣ等は省略している。ＣＰＵ１２はＲＯＭ１４に記憶されたプログラムを実行して、通信データの中継処理、バス間協調スリープ制御、ＥＣＵの通信異常や端子の断線判定等を行う。これらの処理の中で付け捨て端子が特定される。
【００２９】
ＣＡＮコントローラ１１は、車載ＬＡＮ１又は車載ＬＡＮ２から通信データを受信するとＣＰＵ１２に割り込むなどして受信したことを通知する。通信データは受信バッファ（ＲＡＭ１３の一領域にある）に記憶される。ＣＰＵ１２は、受信バッファに記憶されたデータフレームからＣＡＮ ＩＤを抽出して、フィルタリングポリシーと照らし合わせ、転送が必要か否かを判定する。ＣＰＵ１２は、転送が必要な通信データは送信バッファに記憶して、送信側のＣＡＮコントローラ１１に送信を要求する。送信側のＣＡＮコントローラ１１は、通信データの送信要求を受け付けると上記のようなフレームの各フィールドに、ＣＡＮ ＩＤ（この場合はゲートウェイのＣＡＮ ＩＤ）、データ等を格納し車載ＬＡＮ１，２に送信する。
【００３０】
このように、ゲートウェイ装置１００の端子１にはＥＣＵ１の通信データ、端子２にはＥＣＵ２の通信データが到達するので、ゲートウェイ装置１００は端子に対応づけて各ＥＣＵのＣＡＮ ＩＤを記憶しておく。このＣＡＮ ＩＤが受信情報である。こうすることで、端子１，２に接続されているＥＣＵ１，２を特定することができる（上記のような転送も可能になる）。以下、端子とＣＡＮ ＩＤの関係を登録したデータを端子受信テーブル２５という。
【００３１】
端子受信テーブル２５は例えばＲＡＭ１３に記憶される。ゲートウェイ装置１００にはバッテリから電力が供給されるので、ＩＧ−ＯＦＦしてもＲＡＭ１３のデータは消去されない。また、ＲＡＭ１３には、ＡＣＫを受信できなかったステータス通知要求の送信回数を端子毎に登録した送信回数テーブル２４、端子毎の停止フラグが登録された停止フラグテーブル２６が記録される。送信回数については後述する。
【００３２】
＜スリープモードについて＞
各ＥＣＵ１、２は、プログラムが動作可能な通常モードと対比して称されるスリープモード（又は省電力モード）で動作することができる。スリープモードは、例えば、ＣＰＵ１２の動作クロックが最小限に低減される状態、ＲＡＭ１３などの最小限のチップにしか電力が供給されない状態など、消費電力を抑制可能な動作モードである。説明のため、プログラムが動作可能なモードを通常モードと称す。よって、スリープモード以外の動作モードが通常モードである。なお、動作クロックが数段階に低減されたり、段階的に電力を供給するチップ数を低減するなど、スリープモードにいくつかの段階があってもよい。
【００３３】
通常モードからスリープモードへの移行条件は、ＥＣＵ毎に様々であるが、例えば、乗員がＩＧオフに操作したこと、ＩＧオフ後、定められた終了処理（アクチュエータを安全に停止させる処理、ＥＣＵハードのアクセスを適切に終了させる処理等）が終了したこと、監視対象の通信線の所定時間の平均電圧が閾値未満であったこと（つまりそのＥＣＵが使用されていない）、等である。
【００３４】
スリープモードから通常モードへの移行条件もＥＣＵ１００によって様々であるが、例えば、乗員がＩＧオンに操作したこと（ハイブリッド車や電気自動車の場合はメインシステムをオンに操作すること）、監視対象の通信線の所定時間の平均電圧が閾値以上であったこと、ユーザ操作が検出されたこと等である。例えば、ＩＧ−ＯＮの場合は、ＥＣＵ（マイコン、又は、ＣＰＵ１２でもよい）及びゲートウェイ装置１００のＷＡＫＥ端子にウェイクアップ信号が入力されることで検出される。スリープモードから通常モードへ移行することをウェイクアップという。
【００３５】
〔ゲートウェイ装置の機能〕
図５は、ゲートウェイ装置１００の機能ブロック図の一例である。ゲートウェイ装置１００は、スリープ制御部２１、停止フラグ操作部２２及び送信処理部２３を有する。スリープ制御部２１は車載ＬＡＮの全てのＥＣＵ１，２がスリープ可能か否かを判断して、バス間協調スリープ制御を行う。送信処理部２３は、ステータス通知要求をＥＣＵ１，２に送信して、ＡＣＫを受信できない回数をカウントする。停止フラグ操作部２２は、送信回数が閾値以上になると停止フラグを１つ大きくする。これにより、ＥＣＵの通信異常若しくは断線、又は、付け捨て端子である場合に停止フラグが大きくなる。また、停止フラグ操作部２２は、受信端子テーブル２５を参照して、ＥＣＵが登録されていない端子の停止フラグに“２”を設定する。
【００３６】
例えば、図の端子受信テーブル２５には、端子１にＥＣＵ１が、端子２にＥＣＵ２が、接続されていること（過去にＥＣＵ１、２から端子１，２に通信データが送信されたこと）が登録されている。また、端子３は付け捨て端子なので、端子３にはＥＣＵが登録されていない。端子受信テーブル２５のＥＣＵ１，２は例えば、ＣＡＮ ＩＤ（図１の受信情報に相当）であるが、過去に受信があったことを記録できればどのような情報でもよい。
【００３７】
＜バス間協調スリープ制御＞
図６を用いて、バス間協調スリープ制御について説明する。図６は、スリープ制御部２１がバス間協調スリープ制御する手順を示すフローチャート図の一例である。図６の処理は、各ＥＣＵがウェイクアップすることで開始され、ゲートウェイ装置１００が各ＥＣＵ１，２にスリープを許可するまでは繰り返し実行される。
【００３８】
まず、スリープ制御部２１はＥＣＵ１，２からスリープ要求があるか否かを判定する（Ｓ１）。
【００３９】
スリープ要求がある場合（Ｓ１のＹｅｓ）、スリープ制御部２１はスリープ要求したＥＣＵ１，２の識別情報（例えば、ＣＡＮ ＩＤ）を登録しておく（Ｓ２）。
【００４０】
スリープ要求したＥＣＵ１，２を登録すると、スリープ制御部２１は車載ＬＡＮ１，２に接続された全てのＥＣＵからスリープ要求があったか否かを判定する（Ｓ３）。すなわち、スリープ制御部２１は端子受信テーブル２５に登録されている全てのＥＣＵ１，２からスリープ要求があったか否かを判定する。
【００４１】
全てのＥＣＵ１，２からスリープ要求があった場合（Ｓ３のＹｅｓ）、スリープしているＥＣＵ１，２に通信データが送信される可能性がないため、スリープ制御部２１は全てのＥＣＵ１，２にスリープを許可する（Ｓ１００）。
【００４２】
全てのＥＣＵ１，２からスリープ要求がない場合（Ｓ３のＮｏ）、通信異常、端子とケーブルの断線、又は、付け捨て端子の可能性があるため、スリープ制御部２１はスリープ要求のないＥＣＵが接続された端子の停止フラグが“３”か否か判定する（Ｓ４）。停止フラグについては後述するが、停止フラグが“３”であるとはその端子とケーブルが断線しているか又は付け捨て端子であることを意味する。
【００４３】
スリープ要求のないＥＣＵが接続された端子の停止フラグが“３”である場合（Ｓ４のＹｅｓ）、スリープ制御部２１は、スリープ制御部２１は全てのＥＣＵにスリープを許可する（Ｓ１００）。
【００４４】
本実施形態では、停止フラグのカウント方法に特徴があり、付け捨て端子については早期にそれを検出し、断線の可能性のある端子については断線の有無を十分に判定することができる。
【００４５】
＜従来の停止フラグの操作＞
図７は、付け捨てか断線かを判別することなく、ゲートウェイ装置１００が停止フラグを操作する従来の手順を示すフローチャート図の一例である。
【００４６】
まず、スリープ制御部２１は各ＥＣＵ及びゲートウェイ装置１００がウェイクアップしたことを検出して、停止フラグをリセットする（Ｓ１０）。停止フラグはウェイクアップ毎に初期化され、その初期値はゼロとする。
【００４７】
バス間協調スリープ制御に至るまで、停止フラグ操作部２２はステータス通知要求の送信処理を繰り返す。すなわち、スリープ制御部２１はサイクル時間が経過したか否かを判定し（Ｓ２０）、サイクル時間が経過する毎に（Ｓ１２のＹｅｓ）、停止フラグ操作部２２は送信回数が閾値以上か否かを判定する（Ｓ３０）。この閾値は上記と同じ例えば“１００”回などであり、断線していると確定してよいか否かが判定されている。
【００４８】
送信回数が閾値以上の場合（Ｓ３０のＹｅｓ）、停止フラグ操作部２２は停止フラグを１つインクリメントする（Ｓ４０）。このように、停止フラグは送信回数が閾値以上になると１つ増えるフラグである。
【００４９】
次に、送信処理部２３に送信処理を要求する（Ｓ５０）。送信処理は、例えばＳ１２のタイマ割込みにより実行されるサブルーチン、メイン関数から呼びだされる関数などである。
【００５０】
これにより、送信処理部２３は定期的に送信処理を行うことができる。
図８は、送信処理の手順を示すフローチャート図の一例である。送信処理部２３は、各ＥＣＵ１，２にステータス通知要求を送信する（Ｓ３０１）。ステータス通知要求を送信すべきＥＣＵ１，２は端子受信テーブル２５に登録されている。または、全ての端子１，２から同報的にステータス通知要求を送信してもよい。
【００５１】
送信処理部２３はＡＣＫを受信したか否かを判定する（Ｓ３０２）。特定のＥＣＵに不具合が生じた場合、特定のＥＣＵのみからＡＣＫが受信できない状況が生じるが、本実施例では、端子１又は端子２から車載ＬＡＮのケーブルが外れているような場合を想定する。特定のＥＣＵの不具合が検出された場合、該ＥＣＵをリセットするなど所定の処理を行う。
【００５２】
端子１のＥＣＵから１つでもＡＣＫを受信した場合、及び、端子２のＥＣＵから１つでもＡＣＫを受信した場合（Ｓ３０２のＹｅｓ）、端子１，２に断線が生じておらず正常に通信可能であることになる。
【００５３】
端子１又は端子２から全くＡＣＫを受信しない場合（Ｓ３０２のＮｏ）、送信処理部２３は端子毎に送信回数をインクリメントする（Ｓ３０３）。送信回数は、ＲＡＭに記憶されている値が初期値であり、ステータス通知要求を送信してＡＣＫが受信されない毎に１つずつ大きくなる。したがって、送信回数が大きいことは断線の可能性が高いことを意味する。
【００５４】
次に、送信処理部２３は停止フラグが２以上か否かを判定する（Ｓ３０４）。停止フラグは断線していると判定してスリープモードに移行するか否かを判定するためのフラグである。閾値である“２”は一例であって、適宜設計できる。
【００５５】
停止フラグが２以上である場合（Ｓ３０４のＹｅｓ）、断線しているためスリープモードに移行すべきなので、送信処理部２３は何もしない。これにより、図７の手順で断線時のスリープモード移行制御が可能になる。
【００５６】
停止フラグが２以上でない場合（Ｓ３０４のＮｏ）、送信処理部２３は送信回数が“閾値＋１”以上か否かを判定する（Ｓ３０５）。この閾値は、断線していると判定してよい程度の数であり例えば“１００”回などである。より具体的には、車両の出荷後又はバッテリ装着後、最初のカウント時だけ合計２回、送信処理部２３は送信回数が閾値以上になるまでカウントする。一度、停止フラグが２以上になると、１回だけ、送信処理部２３は送信回数が閾値以上になるまでカウントする。
【００５７】
このため、送信処理部２３は端子毎にカウントした送信回数をリセットする（Ｓ３０６）。リセットとはゼロに戻すこという。送信回数がリセットされることで、送信処理部２３は、再度、閾値までカウントされるのでＳ３０１〜Ｓ３０３の処理が行われ、断線していなければ、この間にＡＣＫがあることが期待できる。
【００５８】
このように図８では、停止フラグが２以上の場合はステップＳ３０６で送信回数がリセットされず、停止フラグが２以上でない場合にだけ（送信回数が閾値＋１である場合）送信回数がリセットされる。停止フラグが２以上になる時は、必ず送信回数が閾値以上になっている（Ｓ４０のＹｅｓにより）。したがって、停止フラグが２以上になった端子の送信回数は閾値のままＲＡＭ１３に記憶されている。また、次回は、閾値の送信回数が初期値となる。
【００５９】
図７に戻り、停止フラグ操作部２２は、停止フラグが”３”か否かを判定する（Ｓ６０）。停止フラグが３以上であることは、送信回数が２回（出荷後又はバッテリ装着後の初回だけが２回で、それ以降は１回）、閾値以上となったことを意味し、その端子は完全に断線していると判断される判断基準である。
【００６０】
停止フラグが”３”の場合（Ｓ６０のＹｅｓ）、スリープ制御部２１は送信処理の呼び出しを禁止するなどして、その端子への送信処理を停止する（Ｓ７０）。この場合、断線の可能性があるので、ゲートウェイ装置１００は端子番号と通信異常を記録するなどして、後に解析可能としておく。
【００６１】
停止フラグが”３”でない場合（Ｓ６０のＮｏ）、停止フラグは２以下なので、停止フラグ操作部２２はステップＳ１０からの処理を繰り返す。ステップＳ５０の送信処理において、停止フラグが０，１であれば送信回数はリセットされるので、送信回数がゼロからカウントされる。
【００６２】
以上のような処理によれば、それまでゲートウェイ装置１００が正常に通信できていた端子なら、停止フラグが”３”以上になるまで、ＡＣＫの受信の有無を確認できるため好ましいと言える。一方、付け捨て端子がある場合、停止フラグが”３”以上になるまでスリープモードに入れないという不都合が生じる。
【００６３】
そこで、本実施形態のゲートウェイ装置１００は付け捨て端子には過去に通信データが到達していないことを利用して、早期に全てのＥＣＵがスリープモードに入ることを可能にする。
【００６４】
＜本実施形態の停止フラグの操作＞
図９は、付け捨て端子に対応して、停止フラグ操作部２２が停止フラグを操作する手順を示すフローチャート図の一例である。図９の手順において図７と同一部の処理は、簡単に説明する。
【００６５】
図９では、停止フラグをリセットすると、端子に受信履歴があるか否かを判定する（Ｓ１２）。停止フラグ操作部２２は端子受信テーブル２５を参照して、端子毎に１つ以上のＥＣＵが登録されているか否かを判定する。端子３のように付け捨て端子の場合、１つのＥＣＵも登録されていない。
【００６６】
端子３に受信履歴がない場合（Ｓ１２のＮｏ）、停止フラグ操作部２２は停止フラグを２つインクリメントする（Ｓ１４）。端子３に受信履歴がないということは、端子３は出荷時から付け捨てであったと判定してよい。よって、停止フラグを２つインクリメントすることで、送信回数が閾値を２回超えるまでに必要な時間を短縮できる。
【００６７】
端子１，２のように受信履歴がある場合（Ｓ１２のＹｅｓ）、停止フラグ操作部２２は停止フラグを操作しない（Ｓ１６）。よって、端子１，２のように出荷時にケーブルが接続されており、過去にＥＣＵ１，２が通信可能であった場合、従来と同様に、送信処理を行い断線の可能性を判定することができる。
【００６８】
以降の処理について、端子３を例に説明する。ステップＳ１４の処理により停止フラグは“２”になっている。
【００６９】
サイクル時間が経過すると（Ｓ２０のＹｅｓ）、ステップＳ３０では送信回数が閾値以上か否かが判定される。ここで、送信回数は閾値のままＲＡＭ１３に記憶されているが、車両の出荷後又はバッテリ装着後、端子３の送信回数が閾値以上になる処理が１度だけ必要になる。
【００７０】
よって、車両の出荷後又はバッテリ装着後、停止フラグが“２”のまま送信処理が実行される（Ｓ５０）。図８の送信処理では、停止フラグが“２”なので、送信回数はリセットされることなく、端子３の送信回数は閾値以上になるまでインクメントされる。
【００７１】
図９に戻り、送信回数が閾値以上になると（Ｓ３０のＹｅｓ）、停止フラグ操作部２２は停止フラグをインクリメントする（Ｓ４０）。これにより端子３に起因して停止フラグが“３”になる。図８の送信処理では停止フラグは変化しないので、ステップＳ６０の判定がＹｅｓとなり、端子３への送信処理が停止される（Ｓ７０）。
【００７２】
このように、図９のステップＳ１４により、ウェイクアップの後、すぐに停止フラグが“２”になるので、１度だけ送信回数が閾値以上になるまでカウントすれば、ゲートウェイ装置１００は送信処理を停止することができる。
【００７３】
これにより、バス間協調スリープ制御で説明したように、他の端子１，２の車載ＬＡＮに接続された各ＥＣＵがスリープ要求することで、ゲートウェイ装置１００は車載ＬＡＮ１，２に対し協調してスリープを許可することができる。
【００７４】
そして、車両の出荷後又はバッテリ装着後でない場合、送信回数はすでに閾値になっているので、最初のステップＳ３０でＹｅｓとなり、停止フラグは”３”となる（Ｓ４０）。その後、図８の送信処理から戻ると、ステップＳ６０の判定がＹｅｓとなり、端子３への送信処理が停止される（Ｓ７０）。
【００７５】
次回、ＥＣＵ１，２やゲートウェイ装置１００がＩＧ−ＯＮなどによりウェイクアップすると、ウェイクアップ後、ステップＳ１４で停止フラグは“２”になる。また、一度、閾値以上になった端子３の送信回数はＲＡＭ１３に記憶されているので、ステップＳ３０ではウェイクアップの直後に閾値以上になっている。これにより、停止フラグは“３”にインクリメントされ、ウェイクアップ後、すぐに送信処理が停止される（Ｓ７０）。
【００７６】
このように、付け捨て端子である端子３は、一度でも送信回数が閾値以上になると、ウェイクアップの直後から、スリープモードに入るための条件を満たす。したがって、ウェイクアップが２回目以降であれば、ゲートウェイ装置１００は、車載ＬＡＮ１，２のＥＣＵ１，２のスリープ要求しだいですぐにスリープを許可することができる。
【００７７】
〔効果の説明〕
図１０は、端子３に対し、ゲートウェイ装置１００が送信停止するまでの時間を模式的に説明する図の一例である。
（ａ）端子３が付け捨てか否かを判定しない場合
ゲートウェイ装置１００は端子３が付け捨てか否かを判定せず、断線している可能性を判定するため送信回数が２回、閾値（１００回）になるまで送信処理を行う。したがって、他の端子１，２のＥＣＵ１，２がスリープ要求していても、バス間協調スリープ制御が可能になるまでの時間が長くなる。
（ｂ）端子３が付け捨てか否かを判定する、出荷直後又はバッテリ装着直後の場合
出荷直後の端子３の送信回数はゼロとしてＲＡＭ１３に記憶されている。このため、停止フラグを３にするため、送信回数が１回だけ閾値になるまでカウントされる。したがって、従来よりも早期にＥＣＵ１，２の状態に応じてバス間協調スリープ制御が可能になる。なお、端子３の停止フラグは２以上なので、端子３の送信回数は閾値のままＲＡＭ１３に記憶される。
（ｃ）端子３が付け捨てか否かを判定する、出荷後又はバッテリ装着直後の２回目以降の場合
ウェイクアップの直後、端子３の送信回数はすでに閾値に達している。したがって、ゲートウェイ装置１００が１回送信を行うと（アルゴリズム上の処理であり１回も送信を行なわないようにすることも可能である）、停止フラグが３になる。したがって、ウェイクアップの直後、ほとんど時間を費やすことなく、端子３は、ＥＣＵ１，２の状態に応じてバス間協調スリープ制御が可能になる。
【００７８】
図７と９を比較すると明らかなように、従来のロジックと比較して修正点も少ないのでソフトウェア開発のコストも低減できる。
【００７９】
〔付け捨て端子にＥＣＵが接続された場合〕
車両の出荷時に付け捨てであった端子に、出荷後、ディーラーオプションの車載装置（例えば、盗難防止装置、リモートエンジン始動装置）やナビゲーション装置が接続される場合がある。この場合、本実施形態では、付け捨て端子に受信履歴が記録されていないため、装着後（ウェイクアップ後）、停止フラグがすぐに３になるおそれがある。
【００８０】
しかしながら、新しいＥＣＵが接続される場合、作業のため、車両からバッテリが取り外される。このため、ＲＡＭ１３にも電力が供給されなくなり、ＲＡＭ１３に記憶された端子３（端子１，２も）の送信回数はリセットされる。
【００８１】
送信回数がリセットされた場合、送信処理部２３は閾値（１００回）に達するまで送信処理を繰り返すので、その間に、新しいＥＣＵがゲートウェイ装置１００に対しＡＣＫを含む通信データを送信する。これにより、受信端子テーブル２５には端子３にＥＣＵから送信があったことが記録される。
【００８２】
したがって、出荷後に付け捨て端子にＥＣＵが接続されても、停止フラグに”２”が設定されることはなく、出荷時からＥＣＵが接続されている他の端子１，２と同様に、断線が判定されるようになる。
【符号の説明】
【００８３】
１１ ＣＡＮコントローラ
１２ ＣＰＵ
１３ ＲＡＭ
１４ ＲＯＭ
２１ スリープ制御部
２２ 停止フラグ操作部
２３ 送信処理部
２４ 送信回数テーブル
２５ 端子受信テーブル
２６ 停止フラグテーブル
１００ ゲートウェイ装置
２００ 車載システム
【特許請求の範囲】
【請求項１】
複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置であって、
端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段と、
端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段と、
送信異常の回数が第１の閾値以上になった場合に端子毎に設けられるカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値を設定するフラグ処理手段と、
前記カウンタフラグが前記所定値より大きい第２の閾値になった場合、端子に接続されている端末のスリープ条件が成立したと判定するスリープ制御手段と、
を有することを特徴とする車両用通信中継装置。
【請求項２】
前記スリープ制御手段は、他の端子に接続された全ての端末からスリープ要求を受信した場合、前記カウンタフラグが前記第２の閾値になった端子からスリープ要求を受信しなくても、他の端子に接続された全ての端末にスリープを許可する、
ことを特徴とする請求項１記載の車両用通信中継装置。
【請求項３】
前記送信処理手段は、周期的に、端子毎に通信データを送信して端子からの応答がない場合に、送信異常の回数を１つ大きくし、
前記カウンタフラグが前記所定値以上でない場合、送信異常の回数をリセットし、前記カウンタフラグが前記所定値以上の場合、送信異常の回数をリセットしない、
ことを特徴とする請求項１又は２記載の車両用通信中継装置。
【請求項４】
前記カウンタフラグが第２の閾値になった場合、前記送信処理手段は、前記カウンタフラグが第２の閾値になった端子に対する周期的な通信データの送信を停止する、
ことを特徴とする請求項１〜３いずれか１項記載の車両用通信中継装置。
【請求項５】
前記送信処理手段は、前記カウンタフラグが前記所定値以上になりリセットされていない送信異常の回数を、バッテリ電力で記憶内容を維持可能な記憶手段に記録しておき、
端末がスリープから起動した際、前記フラグ処理手段は、前記記憶手段に記憶された送信異常の回数が前記第１の閾値以上になったか否かを判定する、
ことを特徴とする請求項３記載の車両用通信中継装置。
【請求項６】
バッテリ電力の喪失により、前記記憶手段に記憶された送信異常の回数がリセットされた場合、前記送信処理手段は、前記受信情報記憶手段に受信情報が記憶されていない端子に対し、周期的に通信データを送信する、
ことを特徴とする請求項５記載の車両用通信中継装置。
【請求項７】
前記スリープ制御手段は、前記カウンタフラグが第２の閾値になった場合、該端子が付け捨てである又は該端子と端末が断線していると判定する、
ことを特徴とする請求項１〜６いずれか１項記載の車両用通信中継装置。
【請求項８】
端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段を有し、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置のスリープ制御方法であって、
送信処理手段が、端子毎に通信データを送信し、送信異常の回数をカウントするステップと、
フラグ処理手段が、送信異常の回数が第１の閾値以上になった場合に端子毎に設けられるカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値を設定するステップと、
スリープ制御手段が、前記カウンタフラグが前記所定値より大きい第２の閾値になった場合、端子に接続された端末のスリープ条件が成立したと判定するステップと、
を有することを特徴とするスリープ制御方法。
【請求項１】
複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置であって、
端子毎に通信データを送信し、送信異常の回数をカウントする送信処理手段と、
端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段と、
送信異常の回数が第１の閾値以上になった場合に端子毎に設けられるカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値を設定するフラグ処理手段と、
前記カウンタフラグが前記所定値より大きい第２の閾値になった場合、端子に接続されている端末のスリープ条件が成立したと判定するスリープ制御手段と、
を有することを特徴とする車両用通信中継装置。
【請求項２】
前記スリープ制御手段は、他の端子に接続された全ての端末からスリープ要求を受信した場合、前記カウンタフラグが前記第２の閾値になった端子からスリープ要求を受信しなくても、他の端子に接続された全ての端末にスリープを許可する、
ことを特徴とする請求項１記載の車両用通信中継装置。
【請求項３】
前記送信処理手段は、周期的に、端子毎に通信データを送信して端子からの応答がない場合に、送信異常の回数を１つ大きくし、
前記カウンタフラグが前記所定値以上でない場合、送信異常の回数をリセットし、前記カウンタフラグが前記所定値以上の場合、送信異常の回数をリセットしない、
ことを特徴とする請求項１又は２記載の車両用通信中継装置。
【請求項４】
前記カウンタフラグが第２の閾値になった場合、前記送信処理手段は、前記カウンタフラグが第２の閾値になった端子に対する周期的な通信データの送信を停止する、
ことを特徴とする請求項１〜３いずれか１項記載の車両用通信中継装置。
【請求項５】
前記送信処理手段は、前記カウンタフラグが前記所定値以上になりリセットされていない送信異常の回数を、バッテリ電力で記憶内容を維持可能な記憶手段に記録しておき、
端末がスリープから起動した際、前記フラグ処理手段は、前記記憶手段に記憶された送信異常の回数が前記第１の閾値以上になったか否かを判定する、
ことを特徴とする請求項３記載の車両用通信中継装置。
【請求項６】
バッテリ電力の喪失により、前記記憶手段に記憶された送信異常の回数がリセットされた場合、前記送信処理手段は、前記受信情報記憶手段に受信情報が記憶されていない端子に対し、周期的に通信データを送信する、
ことを特徴とする請求項５記載の車両用通信中継装置。
【請求項７】
前記スリープ制御手段は、前記カウンタフラグが第２の閾値になった場合、該端子が付け捨てである又は該端子と端末が断線していると判定する、
ことを特徴とする請求項１〜６いずれか１項記載の車両用通信中継装置。
【請求項８】
端子毎に過去に端末から通信データを受信したことを示す受信情報を記憶する受信情報記憶手段を有し、複数の端子に接続された１つ以上の端末に対しスリープ許可する車両用通信中継装置のスリープ制御方法であって、
送信処理手段が、端子毎に通信データを送信し、送信異常の回数をカウントするステップと、
フラグ処理手段が、送信異常の回数が第１の閾値以上になった場合に端子毎に設けられるカウンタフラグを１つ大きくし、前記受信情報記憶手段に受信情報が記憶されている場合、前記カウンタフラグに所定値を設定するステップと、
スリープ制御手段が、前記カウンタフラグが前記所定値より大きい第２の閾値になった場合、端子に接続された端末のスリープ条件が成立したと判定するステップと、
を有することを特徴とするスリープ制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−１０６２００（Ｐ２０１３−１０６２００Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２４８９２０（Ｐ２０１１−２４８９２０）
【出願日】平成２３年１１月１４日（２０１１．１１．１４）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（０００２３７５９２）富士通テン株式会社 (3,383)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１４日（２０１１．１１．１４）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（０００２３７５９２）富士通テン株式会社 (3,383)
【Ｆターム（参考）】
[ Back to top ]