(57)【特許請求の範囲】
【請求項１】
外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置であって、
前記外部機器から取得する外部情報に基づいて前記通信回線を介しての情報通信の要否を判断する通信要否判断部と、
前記通信要否判断部による情報通信の要否の判断が「要」であること及び通信エラーが検出されることを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する一方、前記通信要否判断部による情報通信の要否の判断が「否」であることを条件に予め定めた送信再開条件が成立するまで通信データの送信を停止する通信制御部と
を備えることを特徴とする通信装置。
【請求項２】
前記通信制御部は、前記通信要否判断部による情報通信の要否の判断が「否」であるとき、通信データの受信を継続するとともに、前記送信再開条件として、前記通信回線を介して通信データが受信されることを含む
請求項１に記載の通信装置。
【請求項３】
前記通信制御部は、前記送信再開条件として、前記通信要否判断部により前記通信回線を介しての情報通信が必要であると判断されることを含む
請求項１又は２に記載の通信装置。
【請求項４】
請求項１〜３のいずれか一項に記載の通信装置において、
当該通信装置が蓄電池を動力源に用いる車両に搭載されている
ことを特徴とする通信装置。
【請求項５】
前記通信要否判断部は、前記外部情報により車両の蓄電池が充電中であることを検知することに基づいて、前記通信回線を介しての情報通信が不要であると判断する
請求項４に記載の通信装置。
【請求項６】
前記通信要否判断部は、前記外部情報により前記通信回線を介しての情報通信を不要とする機器のみが操作されたことを検知することに基づいて、前記通信回線を介しての情報通信が不要であると判断する
請求項１〜５のいずれか一項に記載の通信装置。
【請求項７】
前記通信回線を介しての情報通信を不要とする機器のみの操作として、ドアの開閉操作及びシートポジションの操作の少なくとも一方の操作が含まれる
請求項６に記載の通信装置。
【請求項８】
前記通信要否判断部は、前記通信回線を介して情報通信をする通信相手の有無が取得される外部情報に対応して設定されており、この設定と取得する外部情報とに基づいて前記通信回線を介しての情報通信の要否を判断する
請求項１〜７のいずれか一項に記載の通信装置。
【請求項９】
前記通信要否判断部は、前記通信回線を介して行った情報通信をそのときの外部情報に対応付けて履歴として記憶するとともに、前記記憶した履歴を参照することに基づいて取得する外部情報に対応する通信相手の有無を判定する
請求項１〜８のいずれか一項に記載の通信装置。
【請求項１０】
外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置に用いられる通信方法であって、
前記外部機器から取得する外部情報に基づいて前記通信回線を介しての情報通信の要否を判断する通信要否判断工程と、
前記情報通信の要否の判断が「要」であること及び通信エラーが検出されたことを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する一方、前記情報通信の要否の判断が「否」であることを条件に予め定めた送信再開条件が成立するまで通信データの送信を停止する通信制御工程と
を備えることを特徴とする通信方法。
【請求項１１】
外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置が前記通信回線に複数接続されてなる通信システムであって、
前記通信装置として、請求項１〜９のいずれか一項に記載の通信装置を備える
ことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両などにおいてネットワーク接続される通信装置、及び当該通信装置に用いられる通信方法、及び当該通信装置を含んで構成される通信システムに関する。
【背景技術】
【０００２】
周知のように、車両に搭載された複数の電子制御装置（ＥＣＵ）は、それぞれがネットワーク接続されることによってそれらＥＣＵの有する情報を相互に送受信可能とする車両ネットワークシステムを構成していることが多い。そして、このような車両ネットワークシステムを構成する通信システムの一つにＣＡＮ（コントローラエリアネットワーク）がある。
【０００３】
ところで、ＣＡＮには、通信のエラーを検出するための機能が設けられている。つまり、ＣＡＮでは、ＣＡＮバス上にデータを送信するＥＣＵは、データ送信時にＣＡＮバス上の信号をモニタし、このモニタしている信号と送信したデータに基づく信号とを比較してこれらの信号が一致していれば正しく通信が行なわれたと判定し、逆に一致していなければ通信にエラーが生じていると判定する。
【０００４】
そして、ＣＡＮの仕様によれば、データを送信するＥＣＵで積算された通信エラーのカウント数が２５６未満であれば通常通りの通信が実行される一方、同カウント数が２５６に達すると、ＥＣＵの通信が停止される。なお、このようにして通信が停止されたＥＣＵは、通信エラーのカウントがリセットされることで通信を再開させることができる。そこで、通信を再開させるために通信エラーのカウントを自動的にリセットする技術の一例が特許文献１に提案されている。
【０００５】
特許文献１に記載の通信復帰判定方法は、ＣＡＮ通信が停止された後、通信エラーのカウント数をクリアするとともに、所定時間（例えば、１００ｍｓ）経過後に１回だけ通信（送信）を行なう。そして、この所定時間経過後に１回だけ通信（送信）を行う処理において、通信エラーが検出される場合、引き続き所定時間経過後に１回だけ通信（送信）を行う処理を繰り返す一方、通信エラーが検出されない場合には、通常の通信を再開する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−３３９４１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に記載の技術によれば、ＣＡＮバスに一時的な異常が生じた場合であれ、その後、正常化したときには通信が再開されるようになる。ところで近年は、蓄電池を動力源に用いる車両が多くなるに伴い、通信システムの省電力化も進められるようになってきており、例えば、都度の車両の状態に応じて必要とされるＥＣＵのみを起動させる構成なども考えられている。しかしながら、必要とされるＥＣＵのみが起動されたことを要因として生じる通信エラーとなると、一時的な異常ではないため、通信エラーは維持され続けることとなる。このため、上述のような復帰判定の処理を行ったとしても、ＥＣＵに不要な電力の消費を強いることになってしまう。
【０００８】
本発明は、このような実情に鑑みなされたものであって、その目的は、ＣＡＮプロトコルに基づく通信にあって、通信に消費される電力を抑制することのできる通信装置、及び当該通信装置に用いられる通信方法、及び当該通信装置を含んで構成される通信システムを提供することにある。
【課題を解決するための手段】
【０００９】
以下、上記課題を解決するための手段及びその作用効果を記載する。
【００１０】
上記課題を解決する通信装置は、外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置であって、前記外部機器から取得する外部情報に基づいて前記通信回線を介しての情報通信の要否を判断する通信要否判断部と、前記通信要否判断部による情報通信の要否の判断が「要」であること及び通信エラーが検出されることを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する一方、前記通信要否判断部による情報通信の要否の判断が「否」であることを条件に予め定めた送信再開条件が成立するまで通信データの送信を停止する通信制御部とを備えることを要旨とする。
【００１１】
上記課題を解決する通信方法は、外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置に用いられる通信方法であって、前記外部機器から取得する外部情報に基づいて前記通信回線を介しての情報通信の要否を判断する通信要否判断工程と、前記情報通信の要否の判断が「要」であること及び通信エラーが検出されたことを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する一方、前記情報通信の要否の判断が「否」であることを条件に予め定めた送信再開条件が成立するまで通信データの送信を停止する通信制御工程とを備えることを要旨とする。
【００１２】
上記課題を解決する通信システムは、外部機器に接続されて該外部機器から外部情報を取得するとともに、通信回線に接続されて該通信回線を介してＣＡＮプロトコルに規定される通信データに基づく情報通信を行う通信装置が前記通信回線に複数接続されてなる通信システムであって、前記通信装置として、上記の通信装置を備えることを要旨とする。
【００１３】
このような構成又は方法によれば、情報通信が必要であることと通信エラーが検出されることとを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する、つまり復帰判定を行うことで適時に通信を再開することができる。一方、情報通信が不要であることを条件に、この条件下ではそもそも情報通信が不要であって復帰判定の必要がないことから、予め定めた送信再開条件が成立するまで通信データの送信を停止するようになる。これにより、ＣＡＮプロトコルに基づく通信にあって、不要な通信が抑制され、ひいては通信装置によって通信に消費される電力が抑制されるようになる。
【００１４】
好ましい構成として、前記通信制御部は、前記通信要否判断部による情報通信の要否の判断が「否」であるとき、通信データの受信を継続するとともに、前記送信再開条件として、前記通信回線を介して通信データが受信されることを含む。
【００１５】
このような構成によれば、通信要否判断部による情報通信の要否の判断が「否」であったとしても、車両の状態変化等により通信回線に通信データが流れるようになるときには、その流れている通信データを受信することに基づいて送信再開条件が成立する。つまり、情報通信が不要と判断されたときには、通信装置を電力消費の少ない受信待ちとしつつも、この受信待ちから通信を復帰させることができるようになる。
【００１６】
好ましい構成として、前記通信制御部は、前記送信再開条件として、前記通信要否判断部により前記通信回線を介しての情報通信が必要であると判断されることを含む。
【００１７】
このような構成によれば、通信要否判断部による情報通信の要否の判断が「否」であったとしても、車両の状態変化等により通信要否判断部が情報通信が必要であると判断するようなときには、その判断に基づいて送信再開条件が成立する。つまり、情報通信が不要と判断されたとき、通信に要する電力を抑えつつも、通信を復帰させることができるようになる。
【００１８】
好ましい構成として、上記の通信装置において、当該通信装置が蓄電池を動力源に用いる車両に搭載されている。
【００１９】
このような構成によれば、蓄電池を動力源に用いる車両、例えば、プラグインハイブリッド車や電気自動車などに搭載されている蓄電池の消費量を抑制することができるようになり、蓄電池の蓄電量の維持など図られるようになる。
【００２０】
好ましい構成として、前記通信要否判断部は、前記外部情報により車両の蓄電池が充電中であることを検知することに基づいて、前記通信回線を介しての情報通信が不要であると判断する。
【００２１】
このような構成によれば、特に、蓄電池の充電中に消費される電力を抑えることによって、充電時間の短縮が図られるようになる。
【００２２】
好ましい構成として、前記通信要否判断部は、前記外部情報により前記通信回線を介しての情報通信を不要とする機器のみが操作されたことを検知することに基づいて、前記通信回線を介しての情報通信が不要であると判断する。
【００２３】
このような構成によれば、操作された機器に情報通信が不要なときには情報通信が抑制されるため消費電力の抑制が図られるようになる。
【００２４】
好ましい構成として、前記通信回線を介しての情報通信を不要とする機器のみの操作として、ドアの開閉操作及びシートポジションの操作の少なくとも一方の操作が含まれる。
【００２５】
ドアの開閉操作やシートポジションの操作は、車両の駐車中に行われることもあるが、このように駐車中であれば、それら操作に必要な通信装置のみが起動すればよい。また、それら操作には通信回線を介しての情報通信が不要であることも少なくない。そこで、このような構成によれば、ドアの開閉操作やシートポジションの操作のみのとき情報通信を行わないようにすることで通信装置の消費電力の抑制が図られる。
【００２６】
好ましい構成として、前記通信要否判断部は、前記通信回線を介して情報通信をする通信相手の有無が取得される外部情報に対応して設定されており、この設定と取得する外部情報とに基づいて前記通信回線を介しての情報通信の要否を判断する。
【００２７】
このような構成によれば、通信回線を介しての情報通信の要否が外部情報の種類に応じて判断されるようになるためこうした判断の精度向上が図られるようになる。
【００２８】
好ましい構成として、前記通信要否判断部は、前記通信回線を介して行った情報通信をそのときの外部情報に対応付けて履歴として記憶するとともに、前記記憶した履歴を参照することに基づいて取得する外部情報に対応する通信相手の有無を判定する。
【００２９】
このような構成によれば、情報通信と外部情報とを対応付けて履歴として記憶する。そして、この記憶した履歴を参照することに基づいて、取得する外部情報に応じての通信相手の有無が判定されるようになる。このように履歴を用いることで、例えば車両の出荷後、通信回線に接続される装置の種類や数に変更があったり、機能が変更されて通信相手が変更されたりするようなことがあったとしても、そうした変更にも対応することができる。これにより取得した外部情報に対応する通信相手の有無を好適に判定することができるようになる。
【図面の簡単な説明】
【００３０】
【図１】通信装置を含み構成される通信システムを具体化した第１の実施形態について、その概略構成を示すブロック図。
【図２】ＣＡＮプロトコルに基づく通信メッセージの構成を説明するための説明図。
【図３】同通信システムの通信制御部による通信を停止／再開させる処理の手順を示すフローチャート。
【図４】通信装置を含み構成される通信システムを具体化した第２の実施形態について、その概略構成を示すブロック図。
【図５】同通信システムにおける外部情報に対応して起動するＥＣＵの一例を示すリスト。
【図６】同通信システムにおける外部情報に対応して起動を要するＥＣＵの組み合わせの一例を示すリスト。
【図７】同通信システムの通信装置における通信を停止／再開させる処理の手順を示すフローチャート。
【図８】通信装置を含み構成される通信システムを具体化した第３の実施形態について、その通信装置における通信を停止／再開させる処理を含む手順を示すフローチャート。
【発明を実施するための形態】
【００３１】
（第１の実施形態）
図１〜３に従って、通信装置を含み構成される通信システムを具体化した第１の実施形態について説明する。
【００３２】
図１に示すように、車両１は、通信システムとしての車両ネットワークシステムを備えている。車両１は、外部電源からの充電が可能な蓄電池を動力源として備えているプラグインハイブリッド自動車や電気自動車である。
【００３３】
通信システムは、第１の電子制御装置（ＥＣＵ）１１と、第２のＥＣＵ１２と、それら第１及び第２のＥＣＵ１１，１２を相互通信可能に接続させる通信回路としての通信用バス１０とから構成されている。これにより、第１及び第２のＥＣＵ１１，１２は、制御用の各種情報等を、通信用バス１０を介して相互に授受（送信及び受信）できるようになっている。なお、通信システムは、ＣＡＮ（コントローラエリアネットワーク）として構成されていることから、通信プロトコルにはＣＡＮプロトコルが適用される。
【００３４】
通信用バス１０は、ツイストケーブルなどの通信線などから構成され、その通信線を介してＣＡＮプロトコルにおいて通信における１単位となる通信データとしての通信メッセージを伝達する。なお、通信用バス１０は、通信経路の一部に無線通信を含んでいたり、ゲートウェイなどを介して他のネットワークを経由する経路が含まれていたりしてもよい。
【００３５】
ＣＡＮプロトコルには、通信メッセージの構造であるフレームとして４種類のフレームが規定されており、そのうちの一つにユーザが指定したデータを格納することのできるデータフレームＦｄがある。例えば、ＣＡＮプロトコルの通信データとしての通信メッセージの構造をデータフレームＦｄを例に説明する。
【００３６】
図２に示すように、データフレームＦｄには、主に、通信メッセージの内容を示す「メッセージＩＤ」が格納される領域（図２において「ＩＤ」）や、ユーザが指定したデータが格納される「データフィールド」の領域などが設けられている。この「データフィールド」は０〜６４ビット（８ビット×０〜８バイト）のうちのいずれかの長さで設定される。また、データフレームＦｄには、ＣＡＮプロトコルで規定される、ＳＯＦ（スタートオブフレーム）領域、ＲＴＲ（リモートトランスミッションリクエスト）領域、コントロールフィールド領域、ＣＲＣ（シーアールシー）領域、ＡＣＫ（アクノリッジ）領域、ＥＯＦ領域が確保されている。
【００３７】
このうち、ＡＣＫ領域は、フレームが正常に受信されたことを確認するための領域である。ＡＣＫ領域は、受信側からの応答確認が送信される１ビットのＡＣＫスロットと、ＡＣＫスロットの区切りである１ビットのＡＣＫデリミタとより構成されている。ＡＣＫデリミタは常に「１」（リセッシブ）とされている。ところで通信プロトコルのなかには、データフレームとは別にアクノリッジ用のフレームが用意されているプロトコルもある。しかしながら、ＣＡＮプロトコルの場合、送信側がデータフレームＦｄのＡＣＫスロットを送信しているタイミングで、受信側が確認応答としてアクノリッジを返すようになっている。具体的には、送信側はデータフレームＦｄのＡＣＫスロットに「１」を設定する。受信側は受信しているデータフレームＦｄの内容をＣＲＣ領域に格納されたチェックコードでチェックするとともに、チェックした結果が正常であればＡＣＫスロットに「０」を設定し、異常があるときにはＡＣＫスロットに「１」を設定することでアクノリッジを返す。また、受信側が存在しないとき、ＡＣＫスロットには送信側により設定された「１」が維持される。
【００３８】
これは、ＣＡＮプロトコルでは、通信用バス１０上の信号として、「１」（リセッシブ）よりも「０」（ドミナント）の優先度が高いため、ＡＣＫスロットに送信側が「１」を設定したとしても、受信側が「０」を設定することに応じて、送信側でモニタされるＡＣＫスロットも「０」になるからである。よって送信側は、モニタしているＡＣＫスロットが「０」であることに基づいて送信したデータフレームＦｄが受信側に正常に受信されたことを確認できる。一方、送信側は、モニタしているＡＣＫスロットが「１」であることに基づいて送信したデータフレームＦｄが受信側に正常に受信されていないことを確認できる。よって、送信側はモニタしているＡＣＫスロットが「１」であることを検出することに基づいて、通信エラーのうちのＡＣＫエラーが生じている旨を判断する。また、受信側（他のＥＣＵ）からの応答がないときにも、ＡＣＫ応答がないためＡＣＫエラーが生じている旨を判断する。他のＥＣＵからの応答がない要因には、通信用バス１０に、起動されるＥＣＵが一個だけである車両状態であることや、通信用バス１０への接続が必須とはされていないオプションＥＣＵが全て設けられていない（オプションレス）状態になっていることなどが挙げられる。
【００３９】
なお、ＣＡＮプロトコルの通信メッセージのフレームのうちの一つであるリモートフレームも、上記同様のＡＣＫ領域を有しているため、ＡＣＫエラーの有無を判断することができる。
【００４０】
このようなことからＣＡＮでは、送信側となるＥＣＵは、データフレームＦｄを受信する受信側のＥＣＵが１つも存在しないときにデータフレームＦｄを送信すると、ＡＣＫエラーを検出し、かつ、その検出した通信エラーによりエラーカウントが増加する。なお、ＣＡＮでは、通信エラーのエラーカウントが１２７以下のとき「エラーアクティブ」状態、通信エラーのエラーカウントが１２７を超えるとき「エラーパッシブ」状態、通信エラーのエラーカウントが２５５に達すると「バスオフ」状態になる。「エラーアクティブ」状態は通常の送受信を行う状態であり、「エラーパッシブ」状態は送受信を継続する状態であり、「バスオフ」状態はＥＣＵがネットワークから切り離される状態である。「エラーパッシブ」状態のときには通信エラーのない状態が継続するとカウンタ値が低下して「エラーアクティブ」状態に回復する。しかし、一旦「バスオフ」状態になると、「バスオフ」状態から復帰するためには、例えば、ＥＣＵのリセットやコンフィグレーションを要するなど復帰が容易ではない。そうしたことから本実施形態では、通常のエラー処理として、通信エラーが検出されると、通信エラーのエラーカウントをクリアするとともに、所定時間（例えば、１００ｍｓ）経過後に１回だけ通信（送信）を行なうようにすることで自動的な復帰が可能なエラー処理を行う。なお所定時間は、通信用バス１０の通信負荷を高めることがなく、かつ、復帰に要する遅れの少ない時間が、経験や、実験、理論などに基づいて予め設定される。
【００４１】
図１に示すように、第１及び第２のＥＣＵ１１，１２はそれぞれ、車両１の各種制御に用いられる制御装置であって、例えば、駆動系、走行系、車体系、又は情報機器系等を制御対象にしているＥＣＵである。例えば、駆動系を制御対象とするＥＣＵとしては、エンジンＥＣＵやＨＶ（ハイブリッド）ＥＣＵ、充電制御ＥＣＵが挙げられ、走行系を制御対象とするＥＣＵとしては、ステアリングＥＣＵやブレーキＥＣＵが挙げられる。また、車体系を制御対象とするＥＣＵとしては、ドアＥＣＵやシートＥＣＵ、ライトＥＣＵ、ウィンドウＥＣＵ、エアコンＥＣＵが挙げられ、情報機器系を制御対象とするＥＣＵとしては、オーディオＥＣＵやカーナビゲーションＥＣＵが挙げられる。
【００４２】
第１及び第２のＥＣＵ１１，１２はそれぞれ、外部機器としての監視対象とする機器や制御対象とする機器に配線やＬＩＮ（ローカルインターコネクトネットワーク）などを介して信号を受信可能に接続されている。外部機器は、センサなどにより車両状態に関する情報等を検出するとともに、検出した車両状態を外部情報として出力する。第１及び第２のＥＣＵ１１，１２はそれぞれ、外部機器から出力された信号を外部情報として取得する。外部機器としては、ドアの開閉を検出して制御する装置や、シート形状を検出して制御する装置等が挙げられ、外部情報としては、ドアの開閉情報や操作情報、シート形状情報や操作情報などが挙げられる。
【００４３】
第１及び第２のＥＣＵ１１，１２はそれぞれ、各種制御に要する処理を実行したり、通信情報を処理する情報処理装置１１１と、ＣＡＮプロトコルに基づく通信メッセージを送受信するＣＡＮコントローラ１１２とを備えている。情報処理装置１１１とＣＡＮコントローラ１１２とは内部バスなどを介して接続されており、情報処理装置１１１とＣＡＮコントローラ１１２との間で各種データの授受が可能になっている。そして、第１及び第２のＥＣＵ１１，１２は、情報処理装置１１１やＣＡＮコントローラ１１２などでの処理を通じて上述したＣＡＮプロトコルの通信に関するエラー処理などを行う。
【００４４】
ＣＡＮコントローラ１１２は、通信用バス１０との間で通信メッセージを送受信する。ＣＡＮコントローラ１１２は、ＣＡＮプロトコルに基づく通信メッセージを受信するとともに、ＣＡＮプロトコルに基づく通信メッセージを送信する。つまり、第１及び第２のＥＣＵ１１，１２はそれぞれ、ＣＡＮコントローラ１１２を介して通信用バス１０との間での通信メッセージの送受信を行なう。よって第１及び第２のＥＣＵ１１，１２は、各ＣＡＮコントローラ１１２を介して、ＣＡＮプロトコルに規定されるフレーム構造を有する通信メッセージを相互に送信及び受信可能になっている。
【００４５】
ＣＡＮコントローラ１１２は、通信メッセージに含まれているデータ等を情報処理装置１１１へ提供することができる。また、ＣＡＮコントローラ１１２は、情報処理装置１１１からの提供されるデータ内容や送信指示に基づいて通信メッセージを送信する。
【００４６】
さらに、ＣＡＮコントローラ１１２は、送信している通信メッセージを監視、つまりモニタすることによって送信中の通信メッセージが他の通信メッセージと衝突することを検知し、通信メッセージの衝突を防ぐアービトレーションやＡＣＫ応答の検知などを行う。そして、ＣＡＮコントローラ１１２は、検知したＡＣＫ領域の信号を情報処理装置１１１へ提供する。これにより、情報処理装置１１１では、通信メッセージの送信中にＡＣＫスロットの信号が「１」であるか「０」であるかに基づいて、送信している通信メッセージに対してＡＣＫエラーの有無を検知する。
【００４７】
第１及び第２のＥＣＵ１１，１２の各情報処理装置１１１は、演算装置（ＣＰＵ）や記憶装置を有するマイクロコンピュータを含み構成されている。つまり情報処理装置１１１には、制御用プログラムの演算処理を実行する演算装置と、その制御用プログラムやデータなどが記憶された読み出し専用メモリ（ＲＯＭ）と、演算装置の演算結果が一時的に記憶される揮発性メモリ（ＲＡＭ）とが設けられている。これにより、情報処理装置１１１は、記憶装置に保持されている制御用プログラムを演算装置に読み込み、実行することで、制御対象に対する所定の機能を発揮して当該制御対象の制御を行なう。
【００４８】
情報処理装置１１１は、通信用バス１０を介しての通信メッセージの授受が必要であるか否かを判断する通信要否判断部１１３と、通信メッセージの送受信を制御する通信制御部１１４とを備える。なお、情報処理装置１１１は、記憶装置に保持されている通信メッセージの授受の必要性を判断するプログラム、通信メッセージの送受信を制御するための各種処理を行うプログラムをそれぞれ演算装置に読み込み、実行させる。これにより情報処理装置１１１には、上述した通信要否判断部１１３及び通信制御部１１４の機能が設けられる。
【００４９】
通信要否判断部１１３は、各ＥＣＵ１１，１２に入力される（取得する）外部情報に基づいて、通信用バス１０を介しての通信メッセージの送信などの情報通信が必要であるか否かを判断する（通信要否判断工程）。こうした外部情報は、各ＥＣＵ１１，１２に接続されている外部機器からの操作入力や応答入力などが挙げられる。なお外部情報には、車両のキーポジションの情報や充電中であるとの情報が含まれていてもよい。通信要否判断部１１３は、外部情報からその制御対象に対する処理がそのＥＣＵ単独で可能であると判断する場合、情報通信は不要である、つまり「否」と判断する一方、その他の場合、例えば、外部情報からその制御対象を他の機器と連動させると判断する場合、情報通信は必要である、つまり「要」と判断する。情報通信が不要と判断される制御対象に対する処理の一例としては、駐車中の車両のドアの開閉処理、駐車中の車両のシートを作動させる処理、駐車中の車両のオーディオを作動させる処理などが挙げられる。なお、駐車中であることは、キーポジションが「ＩＧ  ＯＦＦ」であることや、車両１が充電中であることなどから判断することができる。一方、情報通信が必要と判断される制御対象に対する処理の一例としては、駐車中の車両のエアコンを作動させる処理などが挙げられる。ところで、これら処理と情報通信の要否とについては車種や構成の別に相違してもよい。
【００５０】
通信制御部１１４は、通信要否判断部１１３から情報通信が必要であるか否かの判断結果を取得することが可能になっているとともに、ＣＡＮコントローラ１１２の検出するＡＣＫ領域のデータを取得してＡＣＫエラーの有無を判断することが可能になっている。そして通信制御部１１４は、ＡＣＫエラーの有無と、情報通信が必要であるか否かの判断結果とに基づいて、ＣＡＮコントローラ１１２を介して行う情報通信を制御する（通信制御工程）。
【００５１】
詳述すると、通信制御部１１４は、ＡＣＫエラーがない場合、ＣＡＮコントローラ１１２からの通信メッセージの送信を規制せず、通常通りのＣＡＮ通信を行うようにする。
【００５２】
一方、通信制御部１１４は、ＡＣＫエラーがあるとき、情報通信が必要であるか否かの判断結果も参照して情報通信を制御する。つまり、ＡＣＫエラーがある、かつ、情報通信が必要であるとの判断結果である場合、ＣＡＮコントローラ１１２からの通信メッセージの送信を規制せず、通常通りのＣＡＮ通信を維持するとともに、通常のエラー処理を行う。なお、本実施形態では、通常のエラー処理として、例えば、通信エラーが検出されることを条件に通信メッセージの送受信を一定期間（例えば、１００ｍｓ）停止してその一定期間が経過した後に情報通信を再開する処理を行う。よって、ＡＣＫエラーがある、かつ、情報通信が必要であるとの判断結果であると判断される都度、この通常のエラー処理が繰り返される。
【００５３】
一方、ＡＣＫエラーがある、かつ、情報通信が必要ではないとの判断結果であると判断される場合、ＣＡＮコントローラ１１２からの通信メッセージの送信を規制する一方、ＣＡＮコントローラ１１２による通信メッセージの受信は継続する。そして、ＡＣＫエラーがある、かつ、情報通信が必要ではないとの判断結果であるとの判断が維持されるとき、通信メッセージの送信の規制及び受信の維持が継続される。そして、ＣＡＮコントローラ１１２が通信メッセージを受信することに対応して通常のＣＡＮ通信を行う処理に移行する。これにより、送信側のＥＣＵが起動したタイミングでは受信側のＥＣＵは起動していなかったものの、その後の車両状態変化によって起動して情報通信が必要である状態へ変化したとき、その変化に対応することができる。例えば、ＣＡＮコントローラ１１２が受信する通信メッセージとしては、受信側としての他のＥＣＵが起動され、そのＥＣＵにより送信される通信メッセージが挙げられる。
【００５４】
図３を参照して、第１及び第２のＥＣＵ１１，１２の通信エラー処理の動作について説明する。なお、以下では、説明の便宜上、第１のＥＣＵ１１の通信エラー処理について説明し、第２のＥＣＵ１２の通信エラー処理についての説明は割愛する。つまり、送信側を第１のＥＣＵ１１とし、受信側を第２のＥＣＵ１２とする場合について説明する。
【００５５】
第１のＥＣＵ１１は、電源が入れられたり、スリープ状態から起動させられたりすることによって動作を開始するとともに、通常のＣＡＮ通信を開始する（ステップＳ１０）。なおＥＣＵのスリープ状態とは、ＥＣＵが電源は供給されているものの起動する必要のない条件下であるとき、消費電力を抑制するために省電力モードに移行されている状態である。ＥＣＵがスリープ状態とされる車両状態の一例として、自身が充電制御ＥＣＵでないときであれば蓄電池の充電中が挙げられる。そして、ＥＣＵは、省電力モード中に制御対象とする機器が操作されることを条件に、スリープ状態から起動される。ＥＣＵをスリープ状態から起動させる操作の一例として、エアコン操作、オーディオ操作、ドアの開閉、シート位置変更などが挙げられる。すなわち、車両の充電中にユーザにより行われる「暑いのでエアコンをＯＮする」、「暇なのでＴＶを観る」、「乗るためにドアを開ける」、「シートポジションを変える」などの操作によりＥＣＵはスリープ状態から起動される。
【００５６】
ステップＳ１０で通常のＣＡＮ通信が開始されると、第１のＥＣＵ１１は、送信した通信メッセージに応答があるか否かを判断する（ステップＳ１１）。応答があるか否かは、ＡＣＫエラーの有無により定まり、ＡＣＫエラーが無ければ応答があり、ＡＣＫエラーが有れば応答がないと判断される。本実施形態では、第２のＥＣＵ１２が起動しているときには応答があり、第２のＥＣＵ１２が起動していないときには応答がないものとなる。応答があると判断された場合（ステップＳ１１でＹＥＳ）、第１のＥＣＵ１１は、処理をステップＳ１０に戻し、次の通信メッセージによる通常のＣＡＮ通信を開始する、つまり通常のＣＡＮ通信が継続される。一方、応答がないと判断された場合（ステップＳ１１でＮＯ）、第１のＥＣＵ１１は、車両状態が特定の条件下であるか否かを判断する（ステップＳ１２）。ここで車両状態が特定の条件とは、情報通信が必要であるか否かに応じて定まる条件である。詳述すると、情報通信の要否の判断が、必要である（「要」）とされる場合には特定の条件下ではないと判断され、必要ではない（「否」）とされる場合には特定の条件下であると判断される。
【００５７】
特定の条件下ではないと判断された場合（ステップＳ１２でＮＯ）、第１のＥＣＵ１１は、通常の通信エラー処理に基づいて通信を継続する（ステップＳ１３）。通常の通信エラー処理では、復帰判定として、一定の間隔毎（例えば、１００ｍｓ）に通信メッセージの送信が繰り返されてＡＣＫエラーの有無が確認される。よって、通常のエラー処理の場合、第１のＥＣＵ１１は、通信メッセージの送信の都度、電力を消費する。
【００５８】
一方、特定の条件下であると判断された場合（ステップＳ１２でＹＥＳ）、第１のＥＣＵ１１は、通信メッセージの送信を停止する（ステップＳ１４）とともに、通信メッセージの受信を継続するための受信待ち状態に移行する（ステップＳ１５）。特定の条件下であるときはそもそも情報通信が不要であって通信は復帰しないことから、ステップＳ１３に示すような復帰判定は実行されない。よって受信待ち状態のときには通信メッセージの送信が行われないため、第１のＥＣＵ１１の電力消費が抑制される。例えば、間隔が長いとしても、一定の時間毎に通信メッセージを送信することが長時間に渡り行われるようであれば消費される電力量も無視できない。このように電力消費を抑制することによって、車両１の蓄電池を外部電源によって充電しているようなときであれば、ＥＣＵ等の電力消費量の抑制は充電時間の短縮につながることから、こうした電力消費の抑制によって蓄電池を備える車両１のユーザの利便性の向上も図られるようになる。
【００５９】
そして、第１のＥＣＵ１１は、受信待ち状態において、所定の間隔やタイミングで通信メッセージの受信の有無を判断する（ステップＳ１６）。つまり本実施形態では、送信再開条件を、通信メッセージが受信されることとしている。通信メッセージが受信されないと判断した場合（ステップＳ１６でＮＯ）、第１のＥＣＵ１１は、処理をステップＳ１５に戻して再度受信待ち状態となる。一方、通信メッセージが受信されたと判断した場合（ステップＳ１６でＹＥＳ）、第１のＥＣＵ１１は、処理をステップＳ１０に戻し、次の通信メッセージによる通常のＣＡＮ通信を開始する。つまり、一旦受信待ち状態になったとしても、ユーザの新たな操作などによって車両状態に変化が生じ、スリープ状態であったＥＣＵが起動することもある。このため、第１のＥＣＵ１１は、受信待ち状態によって、他のＥＣＵからの通信メッセージを受信できるように準備しておくとともに、他のＥＣＵからの通信メッセージに適切に応答できるようにしておくようにしている。
【００６０】
なお、上述の通信エラー処理の動作は、第１のＥＣＵ１１の起動により実行が開始され、第１のＥＣＵ１１の停止や、リセットによって終了される。
【００６１】
従来、製造時やメンテナンス時に外部装置から、車両装備や車両状況に応じた送信停止条件をＥＣＵに設定して送信を停止させることは可能であった。しかし、本実施形態によれば、車両にＥＣＵが搭載されたままであっても、情報通信が必要なＥＣＵの有無や、他のＥＣＵの起動状態が随時判断され、ＥＣＵからの送信が停止されるようになる。
【００６２】
これにより、ＣＡＮプロトコルに基づく通信にあって、通信に消費される電力を抑制することのできる通信装置、及び当該通信装置に用いられる通信方法、及び当該通信装置を含んで構成される通信システムを提供することができる。
【００６３】
以上説明したように、本実施形態に係る通信システムは、以下に列記する効果を有する。
【００６４】
（１）情報通信が必要であるときにはＡＣＫエラーが検出されることを条件に情報通信を一定期間停止してその一定期間が経過した後に情報通信を再開する、つまり復帰判定を行うことで適時に通信を再開する。一方、情報通信が不要であるときには、そもそも情報通信が不要であって復帰判定の必要がないことから、予め定めた送信再開条件が成立するまで通信メッセージの送信を停止する。これにより、ＣＡＮプロトコルに基づく通信にあって、不要な通信が抑制され、ひいては通信装置によって通信に消費される電力が抑制されるようになる。
【００６５】
（２）通信要否判断部１１３による情報通信の要否の判断が「否」であったとしても、車両１の状態変化等により通信用バス１０に通信メッセージが流れるようになるときには、その流れている通信メッセージを受信することに基づいて送信再開条件が成立する。つまり、情報通信が不要と判断されたときには、ＥＣＵを電力消費の少ない受信待ちとしつつも、この受信待ちから通信を復帰させることができるようになる。
【００６６】
（３）蓄電池を動力源に用いるプラグインハイブリッド車や電気自動車などに搭載されている蓄電池の消費量を抑制することができるようになり、蓄電池の蓄電量の維持などが図られるようになる。
【００６７】
（４）特に、蓄電池の充電中に消費される電力を抑えることによって、充電時間の短縮が図られるようになる。
【００６８】
（５）通信用バス１０を介しての情報通信の要否が外部情報の種類に応じて判断されるようになるためこうした判断の精度向上が図られるようになる。
【００６９】
（第２の実施形態）
図４〜７に従って、通信装置を含み構成される通信システムを具体化した第２の実施形態について説明する。本実施形態では、通信システムの構成がＧＷ（ゲートウェイ）により通信可能に接続された３つの通信用バスを備える構成であることが第１の実施形態の構成と相違するものの、それら３つの通信用バスはＣＡＮプロトコルにより情報通信させるものであることは同様である。そこで、以下では、第１の実施形態にて詳細に説明したＣＡＮプロトコルによる情報通信についての説明は割愛する。なお、車両２は、通信システムと、外部電源からの充電が可能な蓄電池とを備えているプラグインハイブリッド自動車や電気自動車である。
【００７０】
図４に示すように、車両２に設けられている通信システムは、ＧＷ（ゲートウェイ）５０と、それぞれＧＷ５０に接続されている通信回線としての第１のバス２０、第２のバス３０、及び第３のバス４０とを備える。第１〜第３のバス２０，３０，４０は、ＣＡＮプロトコルの通信メッセージを伝送可能なバスとして構成されており、例えばツイストペアケーブルから構成されている。また、ＧＷ５０は、第１〜第３のバス２０，３０，４０から入力されるＣＡＮプロトコルの通信メッセージを、接続されている他のバスへ中継（転送）することができる。よって通信システムは、第１〜第３のバス２０，３０，４０がＧＷ５０を介して相互接続される構成、いわゆるスター型のネットワーク構成を有しているとともに、第１〜第３のバス２０，３０，４０の相互間にＣＡＮプロトコルの通信メッセージを中継（転送）させることができるシステムとして構成されている。
【００７１】
第１〜第３のバス２０，３０，４０にはそれぞれ、複数のＥＣＵが当該バスを介して他のＥＣＵとの間で通信が可能であるように接続されている。第１のバス２０には、例えば、通信装置としてのエアコンＥＣＵ２１と、オーディオＥＣＵ２２とが接続されている。また、第２のバス３０には、通信装置としてのドアＥＣＵ３１、シートＥＣＵ３２、及び充電制御ＥＣＵ３３が接続されている。また、第３のバス４０には、通信装置としてのＨＶＥＣＵ４１と、エンジンＥＣＵ４２とが接続されている。なお、これらのＥＣＵは、図示しないが、第１の実施形態にて説明した、情報処理装置１１１やＣＡＮコントローラ１１２と同様の構成を備えている。
【００７２】
エアコンＥＣＵ２１は、車載エアコンを制御するためのＥＣＵであって、接続されている制御対象としての車載エアコンから操作が入力される。オーディオＥＣＵ２２は、車載オーディオを制御するためのＥＣＵであって、接続されている制御対象としての車載オーディオから操作が入力される。
【００７３】
ドアＥＣＵ３１は、車両のドア６１を制御するためのＥＣＵであって、配線やＬＩＮなどを介して接続されている制御対象としての車両のドア６１用の各ドア装置から操作や状態が入力される。シートＥＣＵ３２は、車両のシート６２を制御するためのＥＣＵであって、配線やＬＩＮなどを介して接続されている制御対象としての車両のシート６２用の各シート装置から操作や状態が入力される。充電制御ＥＣＵ３３は、バッテリ装置６３からの電力の出力や外部電源７０からバッテリ装置６３への電力の充電などを制御するためのＥＣＵであって、配線などにより接続される制御対象としてのバッテリ装置６３の充放電を制御することが可能となっている。なお、充電制御ＥＣＵ３３は、車両２の各部に必要に応じて充電中である旨を示す情報を随時、適切な通信経路を用いて発信することができるようになっている。
【００７４】
ＨＶ（ハイブリッド）ＥＣＵ４１は、バッテリによる駆動とエンジンによる駆動との動力配分の計画や調整を行うＥＣＵである。ＨＶＥＣＵ４１は、ＣＡＮ通信を通じて各種の情報を取得するとともに、そうして取得した各種情報に基づいて、バッテリによる駆動とエンジンによる駆動との計画や調整を行う。エンジンＥＣＵ４２は、内燃機関であるエンジンの駆動を制御するＥＣＵである。エンジンＥＣＵ４２は、配線やＣＡＮにより接続される各種エンジン関連の装置やその他各種装置から得られる各種情報に基づいてエンジンの駆動を制御する。
【００７５】
ＧＷ５０は、１のバスから入力された通信メッセージを、その他のバスに出力する構成を有する装置、いわゆる複数のバスの間に通信メッセージを中継する装置である。よって、複数のバス２０〜４０は、それらバス２０〜４０が接続されているＧＷ５０を介して通信メッセージが相互に送受信される。またＧＷ５０は、いわゆるＥＣＵであって、演算部や記憶部を有するマイクロコンピュータを含み構成されている。よって、ＧＷ５０は、記憶部５４に保持されている制御用プログラムや各種のパラメータを演算部に読み込み、実行処理することで、通信メッセージの中継機能など所定の機能を提供する。また、ＧＷ５０は、外部機器からの車両状態が配線やＬＩＮなどにより入力されるとともに、外部機器からの車両状態としてＣＡＮプロトコルの通信メッセージも入力される。
【００７６】
図５，６に示すように、各ＥＣＵ２１〜４２やＧＷ５０の記憶部５４には、通信の要否の判断に用いられる情報が記憶されている。
【００７７】
図５のリスト８０には、ＧＷ５０と各ＥＣＵ２１〜４２の起動の可・不可もしくは電源入りとキーポジションとの関係の一例が示されている。リスト８０に示すように、記憶部５４等には、キーポジションが「ＩＧ  ＯＦＦ」のときＧＷ５０、エアコンＥＣＵ２１、オーディオＥＣＵ２２、ドアＥＣＵ３１、シートＥＣＵ３２、及び充電制御ＥＣＵ３３が起動可能であること、ＨＶＥＣＵ４１、及びエンジンＥＣＵ４２は起動不可能であることが設定されている。なお、キーポジションが「ＩＧ  ＯＦＦ」のときには、キーポジションが「ＯＦＦ」のときや、キーポジションが「ＡＣＣ」のときなどが含まれる。また、キーポジションが「ＩＧ  ＯＮ」のときＧＷ５０、ドアＥＣＵ３１、シートＥＣＵ３２、充電制御ＥＣＵ３３、ＨＶＥＣＵ４１、及びエンジンＥＣＵ４２に電源が入って起動すること、エアコンＥＣＵ２１、及びオーディオＥＣＵ２２が起動可能であることが設定されている。なお、各ＥＣＵ２１〜４２に記憶される情報については、そのＥＣＵが接続されているバスに関連する情報のみであってもよい。
【００７８】
図６のリスト８１には、外部情報より把握される車両状態とその車両状態に対応して起動する必要のあるＧＷ５０と各ＥＣＵ２１〜４２との関係の一例が示されている。リスト８１に示すように、記憶部５４等には、車両状態としての「エアコンの入／切」、「オーディオの入／切」、「ドアの開／閉」及び「シート移動」の操作それぞれについて、ＧＷ５０の通信メッセージの転送の要否と各ＥＣＵ２１〜４２の起動の要否の関係が設定されている。図６において「○」は転送又は起動が必要なことを示し、「×」は転送又は起動が不要なことを示している。詳述すると、「エアコンの入／切」操作が行われるとき、ＧＷ５０の転送が必要、かつ、エアコンＥＣＵ２１と充電制御ＥＣＵ３３との起動が必要である一方、それ以外のＥＣＵの起動は不要であることが設定されている。「オーディオの入／切」操作が行われるとき、オーディオＥＣＵ２２の起動が必要である一方、それ以外のＥＣＵの起動は不要であるとともに、ＧＷ５０の転送も不要であることが設定されている。「ドアの開／閉」操作が行われるとき、ドアＥＣＵ３１の起動が必要である一方、それ以外のＥＣＵの起動は不要であるとともに、ＧＷ５０の転送も不要であることが設定されている。「シート移動」操作が行われるとき、シートＥＣＵ３２の起動が必要である一方、それ以外のＥＣＵの起動は不要であるとともに、ＧＷ５０の転送も不要であることが設定されている。なお、各ＥＣＵ２１〜４２に記憶される情報については、そのＥＣＵが接続されているバスに関連する情報のみであってもよい。
【００７９】
ＧＷ５０は、第１〜第３のバス２０〜４０に接続され、それらバス２０〜４０から通信メッセージを受信するメッセージ受信部５１と、それらバス２０〜４０に通信メッセージを送信するメッセージ送信部５５とを備えている。またＧＷ５０は、受信した通信メッセージの中継要否を判断する通信要否判断部５２と、通信要否判断部５２による判断結果に応じて通信メッセージの送信を制御する通信制御部５３と、通信要否判断部５２によって判断に用いられる情報が記憶される前記記憶部５４とを備えている。
【００８０】
メッセージ受信部５１は、ＣＡＮプロトコルの通信メッセージを受信して、通信メッセージに含まれているデータ等を当該ＧＷ５０の通信要否判断部５２などにて利用可能にする。メッセージ送信部５５は、通信メッセージの送信対象のバス２０〜４０への転送が通信制御部５３により制御される。これにより例えば、ＧＷ５０は、第１のバス２０から受信した通信メッセージを第２，第３のバス３０，４０へ転送したり、第２のバス３０から受信した通信メッセージを第１，第３のバス２０，４０へ転送したり、第３のバス４０から受信した通信メッセージを第１，第２のバス２０，３０へ転送したりする。なお、転送しないバスなどがあってもよい。
【００８１】
通信要否判断部５２は、第１の実施形態の通信要否判断部１１３と同様の機能を有しているものである。通信要否判断部５２は、外部機器から入力される（取得する）情報や通信をしているＥＣＵの情報などの外部情報と、記憶部５４に設定されている通信の要否の判断に用いられる情報に基づいて、通信メッセージの転送による情報通信が必要であるか否かを判断する。通信要否判断部５２は、外部情報から通信をしているＥＣＵが、そのＥＣＵ単独でその制御対象に対する処理が可能であると判断する場合、情報通信は不要と判断する一方、その他の場合、例えば、その制御対象の制御に他の機器も要すると判断する場合、情報通信は必要であると判断する。さらに、通信要否判断部５２は、車両２のキーポジションの情報を取得するとともに、キーポジションの情報と、記憶部５４に設定されている通信の要否の判断に用いられる情報とに基づいて、通信メッセージの転送による情報通信が必要であるか否かを判断する。
【００８２】
よって通信要否判断部５２は、例えば、リスト８０に示すキーポジションが「ＩＧ  ＯＦＦ」に対応する駐車中のとき、リスト８１に示すオーディオを作動させる処理、ドア６１の開閉処理、シート６２を作動させる処理は各ＥＣＵが単独で処理できるため情報通信が不要であると判断する。一方、例えば、キーポジションが「ＩＧ  ＯＦＦ」のとき、エアコンを作動させる処理では、接続されているバスの異なる複数のＥＣＵでの処理が必要であることから情報通信が必要であると判断する。
【００８３】
また、例えば、リスト８０に示すキーポジションが「ＩＧ  ＯＮ」に対応する車両停止中もしくは走行中のとき、リスト８１に示すオーディオを作動させる処理、ドア６１の開閉処理、シート６２を作動させる処理ではＥＣＵが単独で処理できるものの、リスト８０に示すように、ＧＷ５０等の電源が入り作動しているため情報通信が必要と判断される。また、キーポジションが「ＩＧ  ＯＮ」のとき、エアコンを作動させる処理では、接続されているバスの異なる複数のＥＣＵでの処理が必要であることから情報通信が必要であると判断する。
【００８４】
通信制御部５３は、第１の実施形態の通信制御部１１４と同様の機能を有している。通信制御部５３は、通信要否判断部５２から情報通信が必要であるか否かの判断結果を取得することが可能になっているとともに、メッセージ受信部５１の検出するＡＣＫ領域のデータを取得してＡＣＫエラーの有無を判断することが可能になっている。そして通信制御部５３は、ＡＣＫエラーの有無と、情報通信が必要であるか否かの判断結果とに基づいて、メッセージ送信部５５を介して行う情報通信を制御する。
【００８５】
続いて、図７を参照して、各ＥＣＵ２１〜４２やＧＷにおける通信処理の動作について説明する。
【００８６】
まず、オーディオＥＣＵ２２の通信処理の動作について説明する。なお、その他のＥＣＵの通信処理の動作についての説明は割愛する。
【００８７】
オーディオＥＣＵ２２は、電源が入れられたり、スリープ状態から起動させられたりすることによって動作を開始するとともに、通常のＣＡＮ通信を開始する（ステップＳ２０）。通常のＣＡＮ通信が開始されると、オーディオＥＣＵ２２は、送信した通信メッセージに応答があるか否かを判断するとともに、外部情報などに基づいて車両状態を特定する（ステップＳ２２）。特定された車両状態に基づいて、オーディオＥＣＵ２２は、通信対象ＥＣＵがあるか否かを判断する（ステップＳ２３）。通信対象ＥＣＵがあるか否かの判断は、現在のキーポジションと起動しているＥＣＵとの関係（リスト８０参照）や、「オーディオ入／切」操作の処理に必要なＥＣＵとの関係（リスト８１参照）によって判断される。また、送信した通信メッセージに応答があるときには通信対象ＥＣＵがあると判断する。そして、通信対象ＥＣＵがあると判断された場合（ステップＳ２４でＹＥＳ）、オーディオＥＣＵ２２は、通常のエラー処理を継続する（ステップＳ２５）。つまり、オーディオＥＣＵ２２は、一定の間隔を開けて処理をステップＳ２０に戻し、通常のＣＡＮ通信を継続する。
【００８８】
一方、通信対象ＥＣＵがないと判断された場合（ステップＳ２４でＮＯ）、オーディオＥＣＵ２２は、通信メッセージの送信を停止するとともに、通信メッセージの受信を継続するための受信待ち状態に移行する（ステップＳ２６）。そして、通信メッセージが受信されたと判断されることに基づいて、オーディオＥＣＵ２２は、処理をステップＳ２０に戻し、通常のＣＡＮ通信を開始する。
【００８９】
続いて、同じく図７を参照して、ＧＷ５０の通信処理の動作について説明する。
【００９０】
ＧＷ５０は、電源が入れられたり、スリープ状態から起動させられたりすることによって動作を開始するとともに、通信メッセージの転送可能に通常のＣＡＮ通信を開始する（ステップＳ２０）。ＧＷ５０は、この通常のＣＡＮ通信において各バス２０〜４０において応答するＥＣＵの有無を判断することができる。つまり、ＧＷ５０は、各バス２０〜４０の別に、各バスに応答するＥＣＵの有無を判断する。通常のＣＡＮ通信が開始されると、ＧＷ５０は、外部情報などに基づいて車両状態を特定する（ステップＳ２２）とともに、特定された車両状態に基づいて、通信対象となる応答するＥＣＵがあるか否かをバスの別に判断する（ステップＳ２３）。そしてバスの別に、応答するＥＣＵがあると判断された場合（ステップＳ２４でＹＥＳ）、ＧＷ５０は、当該バスに対しては通常の通信エラー処理に基づいて通信を継続する（ステップＳ２５）。つまり、ＧＷ５０は、処理をステップＳ２０に戻し、通信メッセージの転送可能に通常のＣＡＮ通信を継続する。
【００９１】
一方バスの別に、応答するＥＣＵがないと判断された場合（ステップＳ２４でＮＯ）、ＧＷ５０は、当該バスに対しては通信メッセージの送信を停止するとともに、通信メッセージの受信を継続するための受信待ち状態に移行する（ステップＳ２６）。そして、当該バスで通信メッセージが受信されたと判断されると、ＧＷ５０は、処理をステップＳ２０に戻し、通信メッセージの転送可能に通常のＣＡＮ通信を開始する。
【００９２】
これにより、ＣＡＮプロトコルに基づく通信にあって、通信に消費される電力を抑制することのできる通信装置、及び当該通信装置に用いられる通信方法、及び当該通信装置を含んで構成される通信システムを提供することができる。
【００９３】
以上説明したように、本実施形態に係る通信システムは、上記第１の実施形態にて記載した（１）〜（５）の効果に加えて、以下に列記する効果を有する。
【００９４】
（６）ユーザに操作された機器に情報通信が不要なときには情報通信が抑制されるため消費電力の抑制が図られるようになる。
【００９５】
（７）ドアの開閉操作やシートポジションの操作は、車両２の駐車中に行われることもあるが、このように駐車中であれば、それら操作に必要な通信装置のみが起動すればよい。また、それら操作には通信回線を介しての情報通信が不要であることもある。そこで、ドアの開閉操作やシートポジションの操作のみのとき情報通信を行わないようにすることで通信装置の消費電力の抑制が図られる。
【００９６】
（第３の実施形態）
通信システムを具体化した第３の実施形態について、図８を参照して説明する。本実施形態では、通信対象のＥＣＵの有無の判断に、通信履歴を用いることが第１の実施形態と相違するものの、その他の構成については同様である。そこで、以下では、第１の実施形態と相違する構成について主に説明することとし、同様の構成についてはその詳細な説明を割愛する。
【００９７】
本実施形態では、例えば、第１のＥＣＵ１１には、各種の車両状態と、その車両状態のときに通信したことのあるＥＣＵとが履歴として保持されている。こうした履歴は、各車両状態について、最新の情報が保持されている。なお、最新の情報２つ以上を履歴として保持していてもよい。また、履歴の内容について、所定期間以上や一定の起動回数以上の間更新されない内容については削除するようにしてもよい。
【００９８】
図８に示す通信エラー処理の動作について、本実施形態では第１のＥＣＵ１１を例に説明する。
【００９９】
第１のＥＣＵ１１は、電源が入れられたり、スリープ状態から起動させられたりすることによって動作を開始するとともに、通常のＣＡＮ通信を開始する（ステップＳ３０）。通常のＣＡＮ通信が開始されると、第１のＥＣＵ１１は、送信した通信メッセージに応答がないことを検知する（ステップＳ３１）。なお、送信した通信メッセージに応答がある場合、図示しないが通常のＣＡＮ通信が行われる。そして、応答がないことが検知されると、第１のＥＣＵ１１は、通信履歴の確認を行う（ステップＳ３２）。通信履歴の確認では、外部情報に基づいて車両状態を特定するとともに、当該車両状態において過去に通信したＥＣＵの有無を取得する。そして、第１のＥＣＵ１１は、当該車両状態において過去に通信したＥＣＵの有無を判断する（ステップＳ３３）。
【０１００】
当該車両状態において過去に通信したＥＣＵがあると判断した場合（ステップＳ３３でＹＥＳ）、第１のＥＣＵ１１は、通常の通信エラー処理に基づいて通信を継続する（ステップＳ３４）とともに、こうした通常の通信エラー処理が所定の確認回数以上繰り返されたか否かを判断する（ステップＳ３５）。通信エラー処理が所定の確認回数以上繰り返されていないと判断した場合（ステップＳ３５でＮＯ）、第１のＥＣＵ１１は、処理をステップＳ３０に戻し、通常のエラー処理をしつつ通常のＣＡＮ通信を継続する。つまり、通常のエラー処理における通信メッセージの送信の都度、第１のＥＣＵ１１は電力を消費する。
【０１０１】
一方、当該車両状態において過去に通信したＥＣＵがないと判断された場合（ステップＳ３３でＮＯ）、又は、通信エラー処理が所定の確認回数以上繰り返されたと判断した場合（ステップＳ３５でＹＥＳ）、第１のＥＣＵ１１は、通信メッセージの送信を停止する（ステップＳ３６）。この通信メッセージの送信停止では、第１のＥＣＵ１１は、通信メッセージの受信を継続するための受信待ち状態に移行するため電力消費が抑制される。また、図示しないが、受信待ち状態においては、通信メッセージが受信されることに応じて、第１のＥＣＵ１１は、処理をステップＳ３０に戻し、次の通信メッセージによる通常のＣＡＮ通信を開始する。
【０１０２】
なお、この通信エラー処理の動作は、第１のＥＣＵ１１の起動により実行が開始され、第１のＥＣＵ１１の停止や、リセットによって終了される。
【０１０３】
以上説明したように、本実施形態に係る通信システムは、上記第１の実施形態にて記載した（１）〜（５）の効果に加えて、以下に列記する効果を有する。
【０１０４】
（８）情報通信と外部情報とを対応付けて履歴として記憶する。そして、この記憶した履歴を参照することに基づいて、取得する外部情報に応じての通信相手となるＥＣＵの有無が判定される。このように履歴を用いることで、例えば車両の製造工場出荷後、通信用バスに接続されるＥＣＵ等の種類や数に変更があったり、機能が変更されて通信相手となるＥＣＵが変更されたりするようなことがあったとしても、そうした変更にも対応することができる。これにより取得した外部情報に対応する通信相手の有無を好適に判定することができるようになる。
【０１０５】
（その他の実施形態）
なお上記各実施形態は、以下の態様で実施することもできる。
【０１０６】
・上記各実施形態では、データフレームは標準フォーマットである場合について例示した。しかしこれに限らず、データフレームは拡張フォーマットであってもよい。これにより、通信システムの設計自由度の向上が図られるようになる。
【０１０７】
・上記各実施形態では、通信バスの数が１又は３である場合について例示したが、これに限らず、通信バスの数は２や４以上でもよい。これにより、こうした通信システムの適用可能性の拡張が図られるようになる。
【０１０８】
・上記各実施形態では、通信用バス１０や第１〜第３のバス２０，３０，４０に接続されるＥＣＵ等の数が２つ又は３つである場合について例示した。しかしこれに限らず、バスに接続されるＥＣＵ等の数は、ＣＡＮプロトコルの規格に適合する数であればよく、４つ以上であってもよい。これにより、通信システムの構成の自由度の向上が図られる。
【０１０９】
・上記各実施形態では、ＥＣＵ１１，１２，２１〜４２は、通信要否判断部１１３と通信制御部１１４とを備える構成である場合について例示したが、通信要否判断部と通信制御部とにより発揮される機能を有する構成を備えるのであれば、この構成はどのように区分されていてもよい。
【０１１０】
同様に、上記第２の実施形態では、ＧＷ５０は、メッセージ受信部５１、通信要否判断部５２、通信制御部５３、記憶部５４、メッセージ送信部５５を備える構成である場合について例示した。しかしこれ限らず、ＧＷは、メッセージ受信部、通信要否判定部、通信制御部、記憶部、及びメッセージ送信部より発揮される機能を有する構成を備えるのであれば、この構成はどのように区分されていてもよい。
【０１１１】
これにより、通信システムの設計自由度の向上が図られる。
【０１１２】
・上記各実施形態では、通信再開条件が通信メッセージを受信することである場合について例示した。しかしこれに限らず、通信再開条件として、情報通信の要否の判断が「否」であるとした通信要否判断部がその後の車両の状態変化等により情報通信が必要であると判断するようなときには、その判断に基づいて送信再開条件が成立してもよい。つまり、通信装置は、情報通信が不要との判断により通信に要する電力が抑えられたとしても、必要に応じて好適に通信が復帰されるようになる。
【０１１３】
・上記各実施形態では、情報通信が必要であるか否かの判断にＡＣＫエラーを用いる場合について例示した。しかしこれに限らず、通信相手がないことを特定することができるのであれば、ＡＣＫエラーに基づき生成された「送信が完了しない」旨の信号や、その他のエラーに基づき生成された応答がない旨の信号などに基づいて通信相手がないことを判断してもよい。これにより、通信装置の設計自由度の向上が図られるようになる。
【０１１４】
・上記各実施形態では、各ＥＣＵに通信要否判定部が設けられている場合について例示した。しかしこれに限らず、通信要否判定部は、一部のＥＣＵに設けられていてもよい。これによっても、通信用判定部を有するＥＣＵの電力消費量の抑制が図られるようになる。
【０１１５】
・上記第２の実施形態では、各ＥＣＵ２１〜４２及びＧＷ５０の記憶部５４に、車両状態と、そのときに起動されるＥＣＵとの関係が設定されている場合について例示した。しかしこれに限らず、こうした設定は、必要とされるＥＣＵのみや、ＧＷのみに設定されていてもよい。そして、必要とされるＥＣＵやＧＷのみがこうした設定を参照することを通じて情報通信の要否を判断するようにしてもよい。これにより、通信システムの設計自由の向上が図られるようになる。
【０１１６】
・上記第１，３の実施形態の各ＥＣＵ１１，１２に保持されている情報通信の要否の判断に用いられる情報として、第２の実施形態に示されるリスト８１と同様の情報の少なくとも一部が保持されていてもよい。
【０１１７】
・上記第１，２の実施形態では、ＡＣＫエラーの有無を判断した後に、車両状態を判断する場合について例示した。しかしこれに限らず、情報通信の要否の判断及び必要に応じてのＡＣＫエラーの有無の判断が行われるのであれば、車両状態を判断してからＡＣＫエラーの有無を判断してもよいし、これら判断を並行して行ってもよい。これにより、通信装置の設計自由度の向上が図られるようになる。
【０１１８】
・上記第３の実施形態では、ＡＣＫエラーの有無を判断した後に、通信履歴を確認する場合について例示した。しかしこれに限らず、情報通信の要否の判断及び必要に応じてのＡＣＫエラーの有無の判断が行われるのであれば、通信履歴を確認してからＡＣＫエラーの有無を判断してもよいし、これら判断を並行して行ってもよい。これにより、通信装置の設計自由度の向上が図られるようになる。
【０１１９】
・上記各実施形態では、通信用バスがＣＡＮプロトコルに基づくバスである場合について例示した。しかしこれに限らず、複数の通信装置が接続される通信用バスであって、通信装置が受信側の有無を判断することができるのであれば、通信プロトコルは、ＣＡＮプロトコル以外のプロトコルであってもよい。これにより、通信システムの適用可能性の拡大が図られる。
【０１２０】
・上記各実施形態では、車両１，２はプラグインハイブリッド自動車や電気自動車である場合について例示した。しかしこれに限らず、車両は、ハイブリッド自動車やエンジンのみを駆動源とする自動車であってもよい。また、この通信システムは自動車車両以外の移動体、例えば船舶、鉄道、産業機械やロボットなどに設けられていてもよい。
【符号の説明】
【０１２１】
１，２…車両、１０…通信用バス、１１…第１のＥＣＵ（電子制御装置）、１２…第２のＥＣＵ、２０…第１のバス、２１…エアコンＥＣＵ、２２…オーディオＥＣＵ、３０…第２のバス、３１…ドアＥＣＵ、３２…シートＥＣＵ、３３…充電制御ＥＣＵ、４０…第３のバス、４１…ＨＶＥＣＵ、４２…エンジンＥＣＵ、５０…ＧＷ、５１…メッセージ受信部、５２…通信要否判断部、５３…通信制御部、５４…記憶部、５５…メッセージ送信部、６１…ドア、６２…シート、６３…バッテリ装置、７０…外部電源、１１１…情報処理装置、１１２…ＣＡＮコントローラ、１１３…通信要否判断部、１１４…通信制御部。
【図１】
0005958975.tif 000002
【図２】
0005958975.tif 000003
【図３】
0005958975.tif 000004
【図４】
0005958975.tif 000005
【図５】
0005958975.tif 000006
【図６】
0005958975.tif 000007
【図７】
0005958975.tif 000008
【図８】
0005958975.tif 000009