(57)【特許請求の範囲】
【請求項１】
第１の通信装置および第２の通信装置間の通信を所定の通信線を介して行う通信システムであって、
前記第１の通信装置は、
前記第２の通信装置に送るデータを第１の送信バッファへ格納する第１の制御部と、
前記第１の制御部によって前記第１の送信バッファへ格納されたデータを所定の通信プロトコルに従って前記通信線へ出力する第１の通信部と
を備え、
前記第２の通信装置は、
前記通信線から入力されたデータの受信バッファへの格納および第２の送信バッファへ格納されたデータの前記通信線への出力を前記所定の通信プロトコルに従って行う第２の通信部と、
前記受信バッファへ格納されたデータが所定の通信周期の開始を示すデータであった場合に、前記所定の通信周期内に前記第１の通信装置に送る必要がある全てのデータを前記第２の送信バッファへ一括して格納する第２の制御部と
を備えることを特徴とする通信システム。
【請求項２】
前記通信線へのデータの送出は、前記第２の通信装置からのデータよりも前記第１の通信装置からのデータが優先されることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記第１の制御部は、
前記通信周期よりも短い通信処理周期ごとに前記第２の通信装置に送るデータを前記第１の送信バッファへ格納することを特徴とする請求項１または２に記載の通信システム。
【請求項４】
前記第１の制御部は、
前記通信周期が始まった後の最初の通信処理周期において前記通信周期の開始を示すデータを含むデータを前記第１の送信バッファへ格納することを特徴とする請求項３に記載の通信システム。
【請求項５】
前記第１の通信部および前記第２の通信部は、
前記通信線へのデータ出力をＣＡＮ（Controller  Area  Network）プロトコルに従って実行する通信デバイスであることを特徴とする請求項１〜４のいずれか一つに記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信装置間で通信を行う通信システムに関する。
【背景技術】
【０００２】
従来、エンジンＥＣＵ（Electronic  Control  Unit）やモータＥＣＵなどの電子制御ユニット間の通信方式として、ＣＡＮ（Controller  Area  Network）通信が知られている。ＣＡＮ通信は、電子制御ユニット間で送受信される各種の命令や制御の伝送をＣＡＮバスと呼ばれる通信線を用いて行うものであり、安価で自由度の高い通信方式として広く利用されている（たとえば、特許文献１参照）。
【０００３】
また、ＣＡＮ通信では、マスタやスレーブといった主従関係を決めず、それぞれの電子制御ユニットが任意の通信タイミングでデータの送信を行う所謂マルチマスタ方式が採用されている。
【０００４】
なお、マルチマスタ方式を採用した場合、複数の電子制御ユニットからＣＡＮバスに対してデータが同時に送信されることがあるが、１つのＣＡＮバス上で複数のデータが同時に存在することはできない。このため、ＣＡＮ通信では、データごとに優先順位を設け、優先順位の高いデータから順に伝送を行う通信調停を行うことによって通信の衝突を回避している。
【０００５】
しかしながら、ＣＡＮ通信には、安価で自由度が高い反面、データ通信の効率があまり高くないといった課題がある。たとえば、ＣＡＮ通信では、電子制御ユニット間でデータのやり取りを行う場合に、ＣＡＮバスに無駄な空き時間が生じることがあった。
【０００６】
すなわち、ＣＡＮ通信では、上記のように電子制御ユニット間の通信タイミングが同期されていないため、一方の電子制御ユニットからの送信データがＣＡＮバスに出力されてから他方の電子制御ユニットからの送信データがＣＡＮバスに出力されるまでに無駄な空き時間が生じるおそれがあった。
【０００７】
また、電子制御ユニットは、通信タイミングが到来すると、相手に送信すべきデータを送信バッファへ格納する処理を開始し、かかる処理が完了したのち、送信バッファに格納されたデータをＣＡＮバスへ出力することとしている。このとき、送信バッファへのデータの格納が完了するまでには、ある程度の時間がかかる。すなわち、電子制御ユニットは、通信タイミングが到来したとしても、すぐにはデータを送信することができないため、これによってもＣＡＮバスに無駄な空き時間が生じるおそれがあった。
【０００８】
このようにＣＡＮバスに無駄な空き時間が生じると、特に、所定の制御周期（たとえば、８ｍｓ）においてデータの送受信を複数回繰り返して１つの処理を完了させたい場合に、かかる制御周期内に全てのデータを送信しきれないおそれがある。このことから、車両内の通信で多量のデータを短時間で送受信する必要がある場合には、高速ＵＡＲＴ（Universal  Asynchronous  Receiver  Transmitter）通信などの高速通信方式が用いられている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００３−２６４５６７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、このような高速通信方式は、トランシーバや通信線等といった必要なハードウェア構成が多く、ＣＡＮ通信と比べてコストがかかるという問題がある。
【００１１】
開示の技術は、上述した従来技術による問題点を解消するためになされたものであり、安価な構成でデータ通信の効率を高めることができる通信システムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本願は、第１の通信装置および第２の通信装置間の通信を所定の通信線を介して行う通信システムであって、前記第１の通信装置は、前記第２の通信装置に送るデータを第１の送信バッファへ格納する第１の制御部と、前記第１の制御部によって前記第１の送信バッファへ格納されたデータを所定の通信プロトコルに従って前記通信線へ出力する第１の通信部とを備え、前記第２の通信装置は、前記通信線から入力されたデータの受信バッファへの格納および第２の送信バッファへ格納されたデータの前記通信線への出力を前記所定の通信プロトコルに従って行う第２の通信部と、前記受信バッファへ格納されたデータが所定の通信周期の開始を示すデータであった場合に、前記所定の通信周期内に前記第１の通信装置に送る必要がある全てのデータを前記第２の送信バッファへ一括して格納する第２の制御部とを備えることを特徴とする。
【発明の効果】
【００１３】
本願によれば、安価な構成でデータ通信の効率を高めることができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】図１は、本願に係る通信手法の概要を示す図である。
【図２】図２は、本実施例に係る通信システムの構成例を示す図である。
【図３】図３は、ＨＶ−ＥＣＵおよびモータＥＣＵの構成を示すブロック図である。
【図４】図４は、フレームデータのフレーム構成の一例を示す図である。
【図５】図５は、通信周期内に送信すべきデータと開始ＩＤとの対応関係の一例を示す図である。
【図６】図６は、ＨＶ−ＥＣＵおよびモータＥＣＵの動作例を示す図である。
【図７】図７は、ＣＡＮプロトコルに基づくデータ出力処理の一例を示す図である。
【図８】図８は、所定の通信周期におけるＨＶ−ＥＣＵおよびモータＥＣＵの通信タイミングの一例を示すタイミングチャートである。
【図９】図９は、ＨＶ−ＥＣＵが実行する送信処理の処理手順を示すフローチャートである。
【図１０】図１０は、モータＥＣＵが実行する送信処理の処理手順を示すフローチャートである。
【図１１】図１１は、ＨＶ−ＥＣＵおよびモータＥＣＵが実行する受信処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下に添付図面を参照して、本発明に係る通信システムの実施例を詳細に説明する。まず、実施例の詳細な説明に先立ち、本願に係る通信手法の概要について図１を用いて説明する。図１は、本願に係る通信手法の概要を示す図である。図１の（Ａ）には、従来のＣＡＮ通信の概要を、図１の（Ｂ）には、本願に係る通信手法の概要を、それぞれ示している。
【００１６】
図１の（Ａ）および（Ｂ）では、２周期分の通信処理周期を１つの制御周期として、第１の通信装置および第２の通信装置が、それぞれ８フレームのデータを送信し合う場合の例を示している。ここで、「制御周期」とは、第１の通信装置で行われる所定の制御処理の処理周期のことであり、またここでは、所定の制御処理のために必要な、第１の通信装置および第２の通信装置間で行われる通信処理を完了させる必要がある期間のことでもある。「通信処理周期」とは、通信周期内に通信のために行う処理の処理周期である。なお、以下では、制御周期が通信周期と同じである場合の例について説明するが、制御周期は、通信周期と周期の長さや開始タイミングが異なってもよい。
【００１７】
図１の（Ａ）に示すように、従来のＣＡＮ通信では、第１の通信装置および第２の通信装置間で通信を行う場合に、ＣＡＮバスに無駄な空き時間が生じるおそれがあった。
【００１８】
具体的には、ＣＡＮ通信では、第１の通信装置および第２の通信装置間で通信タイミングが同期されていない。このため、通信タイミングのずれ方によっては、一方の通信装置からの送信データがＣＡＮバスに出力されてから他方の通信装置からの送信データがＣＡＮバスに出力されるまでに無駄な空き時間が生じるおそれがあった。
【００１９】
たとえば、図１の（Ａ）に示した例では、第１の通信装置からのフレームデータ４がＣＡＮバスへ出力されてから第２の通信装置からのフレームデータ１がＣＡＮバスへ出力されるまでの間にこのような空き時間が発生している。また、第１の通信装置からのフレームデータ８がＣＡＮバスへ出力されてから第２の通信装置からのフレームデータ５がＣＡＮバスへ出力されるまでの間においても同様である。
【００２０】
また、第１の通信装置および第２の通信装置のそれぞれは、通信処理周期が到来すると、相手に送信すべきデータを送信バッファへ格納する処理を開始し、かかる処理が完了したのち、送信バッファに格納されたデータをＣＡＮバスへ出力する。このとき、送信バッファへのデータ格納が完了するまでには、ある程度の時間がかかる。すなわち、電子制御ユニットは、通信タイミングが到来しても、すぐにはデータを送信することができないため、これによってもＣＡＮバスに空き時間が生じるおそれがあった。
【００２１】
たとえば、図１の（Ａ）では、第２の通信装置からのフレームデータ４がＣＡＮバスへ出力されてから第１の通信装置からのフレームデータ５がＣＡＮバスへ出力されるまでの間にこのような空き時間が発生している。
【００２２】
このように、ＣＡＮバスに無駄な空き時間が生じると、通信周期内に完了させるべき処理がかかる通信周期内で完了しない場合がある。具体的には、図１の（Ａ）に示したように、通信周期内に送信すべきデータ（ここでは、８つのフレームデータ）を通信周期内に送信しきれないおそれがある。
【００２３】
そこで、本願に係る通信手法では、通信周期内で完了させるべき処理の開始タイミングを第１の通信装置および第２の通信装置間で同期させることとし、かつ、第２の通信装置が、通信周期内で送信すべきデータの全てを送信バッファへ一括して格納することとした。そして、本願に係る通信手法では、送信バッファへ格納されたデータをＣＡＮプロトコルに従ってＣＡＮバスへ順次出力していくことで、ＣＡＮバスに上記のような無駄な空き時間が発生することを防止することとした。
【００２４】
具体的には、図１（Ｂ）に示すように、マスタノードである第１の通信装置は、通信周期（すなわち、第１の通信装置の制御周期）の開始時に、かかる通信周期の開始を示す開始ＩＤを含んだデータを送信バッファへ格納する。かかる開始ＩＤは、専用のＩＤであってもよいし、従来のＣＡＮ通信で用いられるＩＤを流用してもよい。なお、従来のＣＡＮ通信で用いられるＩＤは、データの種別と、後述する通信調停を行う際にデータの優先順位を示すものである。
【００２５】
第１の通信装置は、データを送信バッファへ格納すると、送信バッファへ格納したデータをＣＡＮプロトコルに従ってＣＡＮバスへ出力する（図１の（Ｂ）の（１）参照）。
【００２６】
具体的には、第１の通信装置は、ＣＡＮバスに対してデータを出力する際に、ＣＡＮバスの使用状況を確認し、ＣＡＮバスが使用されていなければ、ＣＡＮバスへのデータ出力を実行する。また、第１の通信装置は、ＣＡＮバスの競合が発生した場合には、相手側（ここでは、第２の通信装置）が送信しようとしているデータの優先順位と自装置が送信しようとしているデータの優先順位とを比較する。そして、自装置が送信しようとしているデータの優先順位が高ければ、相手側よりも先にＣＡＮバスへのデータ出力を行う。一方、相手側のデータの優先度が高ければ、相手側のデータ出力を優先させ、ＣＡＮが空き状態となったのちにＣＡＮバスへのデータ出力を行う。なお、このような処理は「通信調停」と呼ばれる。
【００２７】
ここでは、マスタノードである第１の通信装置から送信されるデータの優先順位が、スレーブノードである第２の通信装置から送信されるデータの優先順位よりも高く設定される。このため、第１の通信装置は、第２の通信装置との間でＣＡＮバスの競合が発生した場合でも、第２の通信装置よりも優先的にＣＡＮバスへのデータ出力を行うこととなる。
【００２８】
第２の通信装置は、第１の通信装置からＣＡＮバスを介してデータを受信すると、受信したデータを受信バッファへ格納する。また、第２の通信装置は、受信バッファへ格納されたデータに開始ＩＤが含まれる場合に、かかる開始ＩＤに対応するデータであって、所定の通信周期内に送信すべき全てのデータ（ここでは、８フレームのデータ全て）を送信バッファへ一括して格納する（図１の（Ｂ）の（２）参照）。
【００２９】
そして、第２の通信装置は、送信バッファへ格納されたデータをＣＡＮプロトコルに従ってＣＡＮバスへ順次出力する。すなわち、第２の通信装置も、第１の通信装置と同様に、通信調停を適宜行いながらＣＡＮバスへのデータ出力を行う。
【００３０】
ここで、第２の通信装置から送信されるデータの優先順位は、上記のように第１の通信装置から送信されるデータの優先順位よりも低く設定されている。このため、第２の通信装置は、ＣＡＮバスへのデータ出力中に、第１の通信装置からＣＡＮバスへのデータ出力がなされると、自装置からのデータ出力を中断し、ＣＡＮバスが空き状態となるのを待ってからデータ出力を再開することとなる（図１の（Ｂ）の（３）参照）。
【００３１】
なお、ここでは、第２の通信装置から送信される全てのデータの優先順位が、第１の通信装置から送信されるデータの優先順位よりも低く設定されるものとするが、これに限ったものではない。すなわち、第２の通信装置から送信されるデータのうち一部のデータの優先順位が、第１の通信装置から送信されるデータの優先順位よりも高く設定されることとしてもよい。ただし、かかる場合であっても、開始ＩＤについては、第２の通信装置から送信される何れのデータよりも優先順位を高く設定しておくものとする。
【００３２】
この結果、ＣＡＮバスには、第１の通信装置からのデータおよび第２の通信装置からのデータがすき間なく出力されることとなり、ＣＡＮバスに無駄な空き時間が生じることが防止される。
【００３３】
このように、本願に係る通信手法では、マスタノードである第１の通信装置が、開始ＩＤを含んだデータをスレーブノードである第２の通信装置へ送信することによって、第１の通信装置および第２の通信装置間で通信タイミングを同期させる。また、本願に係る通信手法では、第２の通信装置が、受信バッファへ格納されたデータに開始ＩＤが含まれる場合に、かかる開始ＩＤに対応するデータであって、通信周期内に送信すべき全てのデータを送信バッファへ格納し、送信バッファへ格納されたデータをＣＡＮプロトコルに従ってＣＡＮバスへ出力することとした。
【００３４】
このため、ＣＡＮバスに無駄な空き時間が生じることがなく、データを効率的に伝送することが可能となる。さらに、本願に係る通信手法は、従来のＣＡＮ通信のハードウェア構成と同一の構成を用いて実現することができる。したがって、本願に係る通信手法によれば、安価な構成でデータ通信の効率を高めることができる。
【００３５】
以下では、本願に係る通信手法を適用した通信システムについての実施例を詳細に説明する。なお、以下の実施例では、通信システムの一例として、車載ＥＣＵ間の通信システムを用いて説明する。また、以下では、パワートレイン系ＥＣＵを制御するＨＶ−ＥＣＵ（Hybrid  Vehicle−ＥＣＵ）を第１の通信装置の一例とし、パワートレイン系ＥＣＵの一つであるモータＥＣＵを第２の通信装置の一例として説明する。
【実施例】
【００３６】
まず、本実施例に係る通信システムの構成例について図２を用いて説明する。図２は、本実施例に係る通信システムの構成例を示す図である。
【００３７】
図２に示すように、本実施例に係る通信システムでは、ＨＶ−ＥＣＵ１とモータＥＣＵ２とが、ＣＡＮバスを介して相互に接続される。ＣＡＮバスは、ＣＡＮ＿ＨｉラインおよびＣＡＮ＿Ｌｏラインからなる２線式の通信線である。また、モータＥＣＵ２は、モータ３と接続する。
【００３８】
ＨＶ−ＥＣＵ１は、マスタノードであり、モータＥＣＵ２等の車両に設けられた各種ＥＣＵと連携してモータ３やエンジン等の全体的な制御を行う。また、モータＥＣＵ２は、スレーブノードであり、ＨＶ−ＥＣＵ１からの命令に従ってモータ３の具体的な制御を行う。
【００３９】
たとえば、ＨＶ−ＥＣＵ１は、ＣＡＮバスを介してモータのトルク指令値をモータＥＣＵ２へ送信する。また、モータＥＣＵ２は、ＣＡＮバスを介してＨＶ−ＥＣＵ１からトルク指令値を受信すると、受信したトルク指令値に基づいてモータ３の制御を行う。また、モータＥＣＵ２は、モータ３に対する制御の結果をＨＶ−ＥＣＵ１へ送信する。かかる一連の処理はあらかじめ決められた所定の通信周期内で行われる。
【００４０】
また、ＨＶ−ＥＣＵ１は、ＣＡＮトランシーバ１１とマイコン１２とを備える。同様に、モータＥＣＵ２も、ＣＡＮトランシーバ２１とマイコン２２とを備える。ここで、ＣＡＮトランシーバ１１，２１、マイコン１２，２２内のハードウェア部、ＣＡＮバスといったハードウェアは、ＣＡＮ通信用のハードウェアをそのまま流用したものである。このように、本実施例に係る通信システムは、ＣＡＮ通信と同様、安価な構成を用いて実現することが可能である。
【００４１】
なお、図２に示すように、ＨＶ−ＥＣＵ１は、モータＥＣＵ２と接続するためのＣＡＮバスとは別に、たとえばエンジンＥＣＵ４や電池ＥＣＵ５といった車両に設けられた様々なＥＣＵと接続するためのバス（たとえば、ＣＡＮバス）とも接続する。
【００４２】
また、図２に示すように、ＨＶ−ＥＣＵ１とモータＥＣＵ２とを接続するＣＡＮバスには、ＨＶ−ＥＣＵ１およびモータＥＣＵ２のみが接続されるものとするが、ＣＡＮバスには３つ以上の通信装置（ＥＣＵ）を接続することも可能である。
【００４３】
次に、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の構成について図３を用いて説明する。なお、図３では、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の特徴を説明するために必要な構成要素のみを示しており、一般的な構成要素についての記載を省略している。
【００４４】
図３に示すように、ＨＶ−ＥＣＵ１は、ＣＡＮトランシーバ１１およびマイコン１２を備える。マイコン１２は、通信部１２１と、送信バッファ１２２と、受信バッファ１２３と、プラットフォーム１２４と、制御部１２５とを備える。制御部１２５は、データ格納処理部１２５ａと、受信完了処理部１２５ｂとを備える。
【００４５】
また、モータＥＣＵ２は、ＣＡＮトランシーバ２１と、マイコン２２とを備える。また、マイコン２２は、通信部２２１と、送信バッファ２２２と、受信バッファ２２３と、プラットフォーム２２４と、制御部２２５とを備える。また、制御部２２５は、ＩＤ読取部２２５ａと、データ格納処理部２２５ｂとを備える。
【００４６】
まず、ＨＶ−ＥＣＵ１の構成について説明する。ＣＡＮトランシーバ１１は、マイコン１２およびＣＡＮバス間のインタフェース用ＩＣ（Integrated  Circuit）である。具体的には、ＣＡＮトランシーバ１１は、マイコン１２で生成されたデータをＣＡＮバスへ出力するとともに、ＣＡＮバスから入力されたデータをマイコン１２へ出力する。
【００４７】
マイコン１２は、モータＥＣＵ２との間の通信をＣＡＮプロトコルに従って制御するマイクロコンピュータである。ここで、かかるマイコン１２のうち、通信部１２１、送信バッファ１２２および受信バッファ１２３は、ハードウェアで構成され、プラットフォーム１２４および制御部１２５は、ソフトウェアで構成される。
【００４８】
通信部１２１は、データの送受信をＣＡＮプロトコルに従って実行するハードウェア部である。具体的には、通信部１２１は、送信バッファ１２２にデータが格納された場合には、かかる送信バッファ１２２に格納されたデータをＣＡＮプロトコルに従ってＣＡＮトランシーバ１１経由でＣＡＮバスへ出力する。また、通信部１２１は、ＣＡＮトランシーバ１１からデータを受け取った場合には、受け取ったデータを受信バッファ１２３へ格納する。なお、ＣＡＮプロトコルに基づき実行されるデータ送信処理（通信調停）の具体例については、図７を用いて後述することとする。
【００４９】
送信バッファ１２２は、他のＥＣＵ（ここでは、モータＥＣＵ２）に対して送信すべきデータを一時的に記憶するハードウェア部である。また、受信バッファ１２３は、他のＥＣＵ（ここでは、モータＥＣＵ２）から受信したデータを一時的に記憶するハードウェア部である。
【００５０】
なお、ＣＡＮトランシーバ１１、通信部１２１、送信バッファ１２２および受信バッファ１２３は、従来のＣＡＮ通信で用いられるＣＡＮトランシーバ、通信部、送信バッファおよび受信バッファを流用することができるが、これに限ったものではない。すなわち、本実施例に係る通信システム専用のトランシーバ、通信部、送信バッファおよび受信バッファを用いてもよい。
【００５１】
プラットフォーム１２４は、ソフトウェア部である制御部１２５によって生成されたデータをハードウェア部である送信バッファ１２２へ渡す処理を行う処理部である。また、プラットフォーム１２４は、ハードウェア部である受信バッファ１２３から受け取ったデータをソフトウェア部である制御部１２５へ渡す処理を行う処理部でもある。
【００５２】
制御部１２５は、たとえばＣＰＵ（Central  Processing  Unit）であり、モータＥＣＵ２との通信に関する処理等を実行するソフトウェア部である。かかる制御部１２５は、特に、データ格納処理部１２５ａと、受信完了処理部１２５ｂとを備える。
【００５３】
データ格納処理部１２５ａは、モータＥＣＵ２への送信データをプラットフォーム１２４経由で送信バッファ１２２へ格納する処理部である。具体的には、データ格納処理部１２５ａは、モータＥＣＵ２へ送信すべきデータを所定のブロック（たとえば、４フレームごと）に分割し、かかる分割データを通信処理周期ごとに送信バッファ１２２へ格納する。
【００５４】
特に、データ格納処理部１２５ａは、通信周期の開始時に、かかる通信周期の開始を示す開始ＩＤを含んだデータを送信バッファ１２２へ格納する。ここで、本実施例に係る通信システムにおいて送受信されるフレームデータのフレーム構成について図４を用いて説明する。図４は、フレームデータのフレーム構成の一例を示す図である。
【００５５】
図４に示すように、フレームデータには、データの内容を表す０〜８Ｂｙｔｅのデータ情報が含まれる。また、フレームデータには、ＩＤが含まれる。ＩＤは、たとえば１１Ｂｉｔであらわされる値であり、従来のＣＡＮ通信においては、データの種別を示す情報であるとともに、通信調停におけるデータの優先順位を示す情報である。
【００５６】
フレームデータに含まれるＩＤには、通常のデータであり、「トルク指令値」や「モータ回転数」といったこのデータの種別と、このデータの優先順位を示す「通常ＩＤ」と、データの優先順位に加え、通信周期の開始を示す「開始ＩＤ」や検査モードにモード移行することを指示する「検査ＩＤ」といった制御情報を含む「制御ＩＤ」の２種類のＩＤが存在する。すなわち、本実施例に係る通信システムでは、従来のＣＡＮ通信で用いられるＩＤに「制御ＩＤ」を設け、この「制御ＩＤ」のひとつとして「開始ＩＤ」を設けることとしている。このように、「開始ＩＤ」は、データの優先順位を示す情報であり、かつ、通信周期の開始を示す情報でもある。
【００５７】
なお、制御情報に付与する制御ＩＤを、通常データに付与する通常ＩＤとは別個に設けることとしてもよい。かかる場合の制御ＩＤは、従来のＣＡＮ通信で用いられるＩＤと同じビット数（ここでは、１１Ｂｉｔ）である必要はなく、より少ないビット数で表現することとしてもよい。
【００５８】
また、ここでは、通信周期の開始を示す情報をＩＤに持たせることとしたが、これに限ったものではなく、たとえば、通信周期の開始を示す命令情報をデータとして格納することとしてもよい。かかる場合、ＩＤは、通常ＩＤにおける何らかのデータをあらわすＩＤで、データ内容だけを命令情報に置き換えるようにしてもよいし、未使用のＩＤを命令情報送信用のＩＤとして用いてもよい。
【００５９】
図３へ戻り、ＨＶ−ＥＣＵ１の制御部１２５についての説明を続ける。受信完了処理部１２５ｂは、モータＥＣＵ２から通信周期内における最終データを受信した場合に、受信完了処理を行う処理部である。たとえば、受信完了処理部１２５ｂは、モータＥＣＵ２から最終データを受信すると、サムチェックを実施し、モータＥＣＵ２から全てのフレームデータを正常に受信できたか否かを判定する。
【００６０】
なお、図３では、制御部１２５が備える処理部として、データ格納処理部１２５ａおよび受信完了処理部１２５ｂのみを示したが、制御部１２５は、モータＥＣＵ２から受信したデータを用いて所定の演算を行う演算処理部などの他の処理部を備えていてもよい。
【００６１】
次に、モータＥＣＵ２の構成について説明する。なお、モータＥＣＵ２のハードウェア、具体的には、ＣＡＮトランシーバ２１、通信部２２１、送信バッファ２２２および受信バッファ２２３は、ＨＶ−ＥＣＵ１のハードウェアと同一構成であるため、ここでの説明は省略する。また、プラットフォーム２２４についても、ＨＶ−ＥＣＵ１のプラットフォーム１２４と同様の処理部であるため、ここでの説明は省略する。
【００６２】
モータＥＣＵ２の制御部２２５は、たとえばＣＰＵであり、ＨＶ−ＥＣＵ１との通信に関する処理等を実行するソフトウェア部である。かかる制御部２２５は、ＩＤ読取部２２５ａと、データ格納処理部２２５ｂなどを備える。
【００６３】
ＩＤ読取部２２５ａは、受信バッファ２２３へ格納されたデータのＩＤを読み取り、読み取ったＩＤが開始ＩＤである場合に、かかる開始ＩＤをデータ格納処理部２２５ｂへ渡す処理を行う処理部である。なお、どのＩＤが開始ＩＤであるかは、あらかじめ決められているものとする。
【００６４】
データ格納処理部２２５ｂは、ＨＶ−ＥＣＵ１への送信データをプラットフォーム２２４経由で送信バッファ２２２へ格納する処理部である。データ格納処理部２２５ｂは、ＩＤ読取部２２５ａから開始ＩＤを受け取ると、受け取った開始ＩＤに対応するデータ、すなわち、通信周期内に送信すべきデータを、所定ブロックごとではなく一括して送信バッファ２２２へ格納する処理を行う。
【００６５】
ここで、通信周期内に送信すべきデータと開始ＩＤとの対応関係について図５を用いて説明する。図５は、通信周期内に送信すべきデータと開始ＩＤとの対応関係の一例を示す図である。
【００６６】
図５に示すように、開始ＩＤには、通信周期内に送信すべきデータがあらかじめ対応付けられている。図５に示した例では、開始ＩＤ「１１１１＊＊＊」には「データＡ」が、開始ＩＤ「１１２２＊＊＊」には「データＢ」がそれぞれ対応付けられている。なお、「データＡ」や「データＢ」は、データの値そのものではなく、データの種別をあらわすものである。
【００６７】
たとえば、データ格納処理部２２５ｂは、トルク閾値を変更する処理の開始を示す開始ＩＤ「１１１１＊＊＊」を受け取ると、モータ３のトルク値などを「データＡ」として取得し、一括して送信バッファ２２２へ格納する。
【００６８】
なお、図３では、制御部２２５が備える処理部として、ＩＤ読取部２２５ａおよびデータ格納処理部２２５ｂのみを示したが、制御部２２５は、他の制御部を備えていてもよい。たとえば、制御部２２５は、ＨＶ−ＥＣＵ１から最終データを受信した場合に、受信完了処理を実行する受信完了処理部や、ＨＶ−ＥＣＵ１から受信した制御命令に従ってモータ３を制御するモータ制御部などを備えていてもよい。
【００６９】
次に、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の動作例について説明する。図６は、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の動作例を示す図である。なお、図６の（Ａ）には、ＨＶ−ＥＣＵ１のデータ送信処理時の動作例を、図６の（Ｂ）には、モータＥＣＵ２がＨＶ−ＥＣＵ１からのデータを受信し、対応するデータを送信バッファ２２２へ格納するまでの動作例を、それぞれ示している。
【００７０】
図６の（Ａ）に示すように、ＨＶ−ＥＣＵ１は、あらたな通信周期が到来すると、モータＥＣＵ２へのデータ送信を開始する。具体的には、ＨＶ−ＥＣＵ１では、データ格納処理部１２５ａが、通信周期内に送信すべきデータを４フレームごとに分割した分割データを自装置の通信処理周期ごとに送信バッファ１２２へ格納する。また、ＨＶ−ＥＣＵ１では、通信部１２１が、送信バッファ１２２に分割データが格納されるごとに、かかる分割データを、ＣＡＮトランシーバ１１を介してＣＡＮバスへ出力する。
【００７１】
ここで、ＨＶ−ＥＣＵ１からモータＥＣＵ２に対して最初に送信される分割データの先頭のデータには、かかる通信周期の開始を示す開始ＩＤが含まれている。ここでは、通信周期内に送信すべきデータを４フレームごとに分割することとしたが、データの分割単位は４フレームである必要はない。
【００７２】
なお、ＨＶ−ＥＣＵ１は、今回の通信周期が開始されると、前回の通信周期においてモータＥＣＵ２から送られてきていた、モータ回転数といったモータの状態に関する情報等や、別のバスから送られてくる運転者のアクセルの踏み込み状態（運転者が求めているトルク量）、電池の充電状態等の車両制御に関する各種情報に基づいて、モータやエンジンで出力する必要があるトルク量（トルク指令値）等を算出する演算処理を行う。
【００７３】
一方、モータＥＣＵ２では、図６の（Ｂ）に示すように、ハードウェア部から受信割り込みを受けると、ＩＤ読取部２２５ａが、ＨＶ−ＥＣＵ１から受信した分割データに含まれるＩＤを読み取る。ＩＤ読取部２２５ａは、読み取ったＩＤの中に開始ＩＤが含まれる場合には、開始ＩＤをデータ格納処理部２２５ｂへ渡す。なお、ここでは、開始ＩＤが「１１１１＊＊＊」であったとする。
【００７４】
データ格納処理部２２５ｂは、ＩＤ読取部２２５ａから開始ＩＤを受け取ると、受け取った開始ＩＤに対応するデータを取得し、取得したデータを一括して送信バッファ２２２へ格納する。ここでは、開始ＩＤ「１１１１＊＊＊」を受け取ったため、データ格納処理部２２５ｂは、かかる開始ＩＤ「１１１１＊＊＊」に対応するデータＡをモータ３などから取得し（図５参照）、取得したデータＡを送信バッファ２２２へ格納する。
【００７５】
なお、モータＥＣＵ２は、ＨＶ−ＥＣＵ１から開始ＩＤを受信すると、取得した現在のモータ回転数といったモータの状態（前回の通信周期で、ＨＶ−ＥＣＵ１から送られてきたトルク指令値等に基づいてモータを制御した後のモータの状態）に関する情報や、前回の通信周期におけるモータＥＣＵ２での演算結果のうち、ＨＶ−ＥＣＵ１に送信する必要があるデータ等を、一括して送信バッファ２２２にセットする。
【００７６】
次に、モータＥＣＵ２の通信部２２１が、送信バッファ２２２に格納されたデータをＣＡＮプロトコルに従ってＣＡＮバスへ出力する処理の動作例について図７を用いて説明する。図７は、ＣＡＮプロトコルに基づくデータ出力処理の一例を示す図である。なお、ここでは、送信バッファ２２２に格納されたデータＡがｎ個のフレームデータで構成される場合の例を示している。
【００７７】
図７に示すように、モータＥＣＵ２の通信部２２１は、ＨＶ−ＥＣＵ１との間で通信調停を適宜行いながら、ＣＡＮバスへのデータ出力を行う。具体的には、通信部２２１は、ＣＡＮバスが空き状態であるか否かを確認し、空き状態であれば、送信バッファ２２２に格納されたデータＡを１フレームずつＣＡＮバスへ出力していく。図７に示した場合には、フレームデータ１〜４がＣＡＮバスへ出力されている。
【００７８】
つづいて、モータＥＣＵ２の通信部２２１がフレームデータ５をＣＡＮバスへ出力しようとした際に、ＨＶ−ＥＣＵ１との間でＣＡＮバスの競合が発生したとする。かかる場合、通信部２２１は、ＨＶ−ＥＣＵ１のデータ出力を優先させ、ＣＡＮが空き状態となったのちに、フレームデータ５をＣＡＮバスへ出力する。これは、モータＥＣＵ２からのデータの優先度が、ＨＶ−ＥＣＵ１からのデータの優先度よりも低く設定されているためである。
【００７９】
このように、モータＥＣＵ２の通信部２２１は、送信バッファ２２２に格納された各フレームデータを絶えずＣＡＮバスへ出力しようとするが、ＨＶ−ＥＣＵ１との間でＣＡＮバスの競合が発生した場合には、ＨＶ−ＥＣＵ１からのデータ出力を優先させる。この結果、ＣＡＮバスには、モータＥＣＵ２からのデータとＨＶ−ＥＣＵ１からのデータとが隙間なく出力されることとなる。すなわち、ＣＡＮバスへのデータの送出は、モータＥＣＵ２からのデータよりもＨＶ−ＥＣＵ１からのデータが優先されることとしたため、ＨＶ−ＥＣＵ１およびモータＥＣＵ２間の通信を、ＣＡＮバスに無駄な空き時間を生じさせることなく行うことができる。
【００８０】
次に、所定の通信周期におけるＨＶ−ＥＣＵ１およびモータＥＣＵ２の通信タイミングについて図８を用いて説明しておく。図８は、所定の通信周期におけるＨＶ−ＥＣＵ１およびモータＥＣＵ２の通信タイミングの一例を示すタイミングチャートである。
【００８１】
ここで、図８では、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の通信処理周期がそれぞれ１ｍｓであり、通信周期（ＨＶ−ＥＣＵ１の制御周期）が８周期分の通信処理周期に相当する８ｍｓであるものとする。また、図８では、ＨＶ−ＥＣＵ１とモータＥＣＵ２との間で、制御周期の開始・終了タイミングの同期を取ることなく、通信処理周期および制御周期の長さのみを同じ長さに設定する場合の例を示している。
【００８２】
図８に示すように、ＨＶ−ＥＣＵ１の制御部１２５は、通信周期が到来すると、前回の通信周期において取得したデータをラッチ（保持）する処理や今回の通信周期において送信したいデータのＳＵＭ値を算出する処理を行う（図８の（１ａ）参照）。ここで、ＳＵＭ値とは、各フレームデータのうちＳＵＭ値を除いた情報（ＩＤやデータ等）を０および１の２進数であらわした情報とした場合に、その値を全て足し合わせた値である。算出されたＳＵＭ値は、各フレームデータに付加されることとなる。
【００８３】
また、ＨＶ−ＥＣＵ１の制御部１２５は、かかる処理を終えたのち、モータＥＣＵ２へ送信するデータの分割データのうち、最初の分割データを送信バッファ１２２へ格納する（図８の（１ｂ）参照）。なお、かかる分割データの先頭のデータには、開始ＩＤが含まれている。
【００８４】
ＨＶ−ＥＣＵ１の送信バッファ１２２に分割データが格納されると、ＨＶ−ＥＣＵ１の通信部１２１は、送信バッファ１２２に格納された分割データをＣＡＮバスへ出力する（図８の（１ｃ）参照）。ＣＡＮバスへ出力された分割データは、モータＥＣＵ２の通信部２２１へ入力され、かかる通信部２２１によって受信バッファ２２３へ格納される。
【００８５】
モータＥＣＵ２の制御部２２５は、受信バッファ２２３に分割データが格納されると、受信割り込みを発生させ、受信バッファ２２３に格納された分割データのＩＤを読み取る（図８の（２ａ）参照）。このとき、モータＥＣＵ２の制御部２２５は、読み取ったＩＤに開始ＩＤが含まれていれば、開始ＩＤに対応する全てのデータを一括して送信バッファ２２２へ格納する（図８の（２ｂ）参照）。
【００８６】
モータＥＣＵ２の通信部２２１は、送信バッファ２２２にデータが格納されると、送信バッファ２２２に格納されたデータを１フレームずつＣＡＮバスへ出力していく。ただし、ＨＶ−ＥＣＵ１との間でＣＡＮバスの競合が発生した場合には、ＨＶ−ＥＣＵ１からのデータ出力が完了するのを待ってからデータ出力を再開させる。
【００８７】
なお、開始ＩＤは、所定の通信周期においてＨＶ−ＥＣＵ１から最初に送信されるデータに埋め込まれている。このため、モータＥＣＵ２は、通信周期内に送信すべきデータを送信バッファ２２２へ格納する処理を通信周期における早い段階で開始することができる。これにより、ＨＶ−ＥＣＵ１からの最初の通信処理周期における最終フレームがＣＡＮバスへ出力されてから、モータＥＣＵ２からの最初のデータがＣＡＮバスへ出力されるまでの間に、ＣＡＮバスの空き時間が生じることを確実に防止することができる。
【００８８】
一方、ＨＶ−ＥＣＵ１の制御部１２５は、通信周期内に受信すべきデータの最終フレームをモータＥＣＵ２から受信すると、受信完了処理を実行する（図８の（１ｄ）参照）。具体的には、ＨＶ−ＥＣＵ１では、受信完了処理部１２５ｂが、通信周期内に受信したデータのＳＵＭ値を算出し、算出したＳＵＭ値をＨＶ−ＥＣＵ１から送信されたＳＵＭ値と比較することで、ＳＵＭ値が正常であるか否かのサムチェックを行う。
【００８９】
なお、ここでは、１つの通信周期で受信した全てのフレームデータのＳＵＭチェックをまとめて行う場合の例を示したが、これに限らず、フレームデータを受信するごとにＳＵＭチェックを実行することとしてもよい。
【００９０】
また、モータＥＣＵ２の制御部２２５も同様に、通信周期内に受信すべきデータの最終フレームをＨＶ−ＥＣＵ１から受信すると、受信完了処理を実行する（図８の（２ｃ）参照）。
【００９１】
次に、ＨＶ−ＥＣＵ１およびモータＥＣＵ２の具体的動作について説明する。まず、ＨＶ−ＥＣＵ１が実行する送信処理の処理手順について図９を用いて説明する。図９は、ＨＶ−ＥＣＵ１が実行する送信処理の処理手順を示すフローチャートである。なお、図９においては、１つの通信周期における送信処理の処理手順を示している。
【００９２】
図９に示すように、ＨＶ−ＥＣＵ１のデータ格納処理部１２５ａは、あらたな通信周期が到来すると、モータＥＣＵ２へ送信するデータの分割データのうち、最初の分割データを送信バッファ１２２へ格納する（ステップＳ１０１）。かかる分割データの先頭のフレームデータには、開始ＩＤが含まれている。また、送信バッファ１２２に分割データが格納されると、ＨＶ−ＥＣＵ１の通信部１２１は、送信バッファ１２２に格納された分割データをＣＡＮプロトコルに従ってＣＡＮバスへ出力する（ステップＳ１０２）。
【００９３】
つづいて、ＨＶ−ＥＣＵ１のデータ格納処理部１２５ａは、次の通信処理周期が到来したか否かを判定し（ステップＳ１０３）、次の通信処理周期が到来したと判定した場合には（ステップＳ１０３，Ｙｅｓ）、次の分割データを送信バッファ１２２へ格納する（ステップＳ１０４）。そして、分割データが送信バッファ１２２へ格納されると、通信部１２１が、かかる分割データをＣＡＮバスへ出力する（ステップＳ１０５）。
【００９４】
なお、本実施例では、マスタノードであるＨＶ−ＥＣＵ１からのデータが、スレーブノードであるモータＥＣＵ２からのデータと比べて優先順位が高く設定されている。このため、通信部１２１は、送信バッファ１２２に分割データが格納されると、モータＥＣＵ２との間でＣＡＮバスの競合が発生した場合であっても、モータＥＣＵ２よりも優先的にデータ出力を行うこととなる。
【００９５】
つづいて、データ格納処理部１２５ａは、全ての分割データの送信が完了したか否かを判定し（ステップＳ１０６）、完了していない場合には（ステップＳ１０６，Ｎｏ）、ステップＳ１０３へ戻り、全ての分割データの送信が完了するまでステップＳ１０３〜Ｓ１０６の処理を繰り返す。なお、ステップＳ１０３において次の通信処理周期が到来していない場合にも（ステップＳ１０３，Ｎｏ）、処理をステップＳ１０３へ戻す。そして、データ格納処理部１２５ａは、全ての分割データの送信が完了すると（ステップＳ１０６，Ｙｅｓ）、処理を終了する。
【００９６】
次に、モータＥＣＵ２が実行する送信処理の処理手順について図１０を用いて説明する。図１０は、モータＥＣＵ２が実行する送信処理の処理手順を示すフローチャートである。なお、図１０においては、モータＥＣＵ２が、開始ＩＤを含んだ分割データを受信してからかかる開始ＩＤに対応するデータの送信を完了させるまでの処理手順を示している。
【００９７】
図１０に示すように、モータＥＣＵ２のＩＤ読取部２２５ａは、ＨＶ−ＥＣＵ１からデータを受信したか否かを判定する（ステップＳ２０１）。具体的には、ＩＤ読取部２２５ａは、受信バッファ２２３にデータが格納されたか否かを判定する。
【００９８】
かかる処理において、データを受信した（すなわち、受信バッファ２２３にデータが格納された）と判定すると（ステップＳ２０１，Ｙｅｓ）、ＩＤ読取部２２５ａは、受信バッファ２２３に格納されたデータから開始ＩＤを読み取る（ステップＳ２０２）。なお、ステップＳ２０１においてデータを受信していない場合、すなわち、受信バッファ２２３にデータが格納されていない場合（ステップＳ２０１，Ｎｏ）、ＩＤ読取部２２５ａは、ステップＳ２０１の判定処理を繰り返す。
【００９９】
つづいて、データ格納処理部２２５ｂは、ＩＤ読取部２２５ａが読み取った開始ＩＤに対応するデータを送信バッファ２２２へ全て格納する（ステップＳ２０３）。つづいて、モータＥＣＵ２の通信部２２１は、送信バッファ２２２にデータが格納されると、まず、ＣＡＮバスが使用可能か否かを判定する（ステップＳ２０４）。具体的には、通信部２２１は、ＣＡＮバスが空き状態である場合（すなわち、ＨＶ−ＥＣＵ１によって使用されていない場合）にＣＡＮバスが使用可能であると判定する。かかる処理において、ＣＡＮバスが使用可能であると判定すると（ステップＳ２０４，Ｙｅｓ）、通信部２２１は、送信バッファ２２２に格納されたデータの１フレームをＣＡＮバスへ出力する（ステップＳ２０５）。
【０１００】
一方、通信部２２１は、ＨＶ−ＥＣＵ１との間でＣＡＮバスの競合が発生した場合には、ＣＡＮバスが使用不可であると判定する（ステップＳ２０４，Ｎｏ）。かかる場合、通信部２２１は、ステップＳ２０４の判定処理を繰り返す。すなわち、通信部２２１は、ＨＶ−ＥＣＵ１のデータ出力を優先させ、ＣＡＮバスが空き状態となったのちにＣＡＮバスへのデータ出力を行う。
【０１０１】
つづいて、通信部２２１は、送信バッファ２２２に格納された全てのデータの送信が完了したか否かを判定し（ステップＳ２０６）、完了していない場合には（ステップＳ２０６，Ｎｏ）、ステップＳ２０４へ戻り、データの送信が全て完了するまでステップＳ２０４〜Ｓ２０６の処理を繰り返す。そして、全てのデータの送信が完了すると（ステップＳ２０６，Ｙｅｓ）、処理を終了する。
【０１０２】
次に、ＨＶ−ＥＣＵ１およびモータＥＣＵ２が実行する受信処理の処理手順について図１１を用いて説明する。図１１は、ＨＶ−ＥＣＵ１およびモータＥＣＵ２が実行する受信処理の処理手順を示すフローチャートである。なお、図１１においては、１つの通信周期における受信処理の処理手順を示している。また、ここでは一例として、ＨＶ−ＥＣＵ１を主体として説明する。
【０１０３】
図１１に示すように、ＨＶ−ＥＣＵ１の制御部１２５は、データを受信したか否か（すなわち、ＣＡＮバスからデータが入力されたか否か）を判定する（ステップＳ３０１）。そして、通信部１２１は、データを受信したと判定すると（ステップＳ３０１，Ｙｅｓ）、受信データを受信バッファ１２３へ格納する（ステップＳ３０２）。なお、通信部１２１は、データを受信していない場合には（ステップＳ３０１，Ｎｏ）、ステップＳ３０１の判定処理を繰り返す。
【０１０４】
つづいて、通信部１２１は、通信周期内に受信すべき全てのデータをモータＥＣＵ２から受信したか否かを判定し（ステップＳ３０３）、未受信のデータがある場合には（ステップＳ３０３，Ｎｏ）、ステップＳ３０１へ戻り、ステップＳ３０１〜Ｓ３０３の処理を繰り返す。一方、全てのデータを受信したと判定した場合には（ステップＳ３０３，Ｙｅｓ）、処理をステップＳ３０４へ移行する。
【０１０５】
ステップＳ３０４において、受信完了処理部１２５ｂは、今回の通信周期内に受信したデータのＳＵＭ値を算出し、かかるＳＵＭ値が正常であるか否かを判定する（ステップＳ３０４）。なお、かかる判定は、ＨＶ−ＥＣＵ１から送信されたＳＵＭ値との比較により行われる。
【０１０６】
かかる処理において、ＳＵＭ値が正常であると判定すると（ステップＳ３０４，Ｙｅｓ）、制御部１２５は、今回の通信周期で受信したデータを次の通信周期が開始される直前に公開して（ステップＳ３０５）、処理を終了する。公開されたデータは、次の通信周期の開始時においてラッチされ、ＳＵＭ値が算出される。一方、ＳＵＭ値が正常ではない場合には（ステップＳ３０４，Ｎｏ）、所定の異常対応処理を行ったうえで（ステップＳ３０６）、処理を終了する。
【０１０７】
なお、図１１では、ステップＳ３０５に示したように、次の通信周期の開始直前に受信データを公開することとしたが、これに限ったものではなく、受信データの公開は、通信周期内における任意のタイミングで行うこととしてもよい。
【０１０８】
上述してきたように、本実施例では、ＨＶ−ＥＣＵのデータ格納処理部が、モータＥＣＵへ送るデータを送信バッファへ格納し、ＨＶ−ＥＣＵの通信部が、送信バッファへ格納されたデータをＣＡＮプロトコルに従ってＣＡＮバスへ出力する。
【０１０９】
また、本実施例では、モータＥＣＵの通信部が、ＣＡＮバスから入力されたデータの受信バッファへの格納および送信バッファへ格納されたデータのＣＡＮバスへの出力をＣＡＮプロトコルに従って行い、モータＥＣＵのデータ格納処理部が、受信バッファへ格納されたデータが開始ＩＤであった場合に、所定の通信周期内にＨＶ−ＥＣＵへ送る必要がある全てのデータを送信バッファへ格納することとした。したがって、安価な構成でデータ通信の効率を高めることができる。言い換えれば、安価な構成を用いつつも、大量のデータ通信を短時間で送受信させることが可能となる。
【０１１０】
以上、本発明に係る通信システムの実施例のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【０１１１】
たとえば、上述してきた実施例では、ＨＶ−ＥＣＵ１が、予め演算していた（すなわち、前回の通信周期で演算していた）１周期（今回の通信周期）に送信する必要があるデータを、所定周期（通信処理周期）ごとに分割して送信バッファ１２２にセットする場合の例について説明した。
【０１１２】
しかし、これに限ったものではなく、ＨＶ−ＥＣＵ１は、通信周期が開始されてから所定の演算を開始し、所定周期（通信処理周期）が経過するごとに、それまでに演算が終わったデータで、まだ送信を行っていないデータを送信バッファ１２２にセットするようにしてもよい。また、かかる場合においてＨＶ−ＥＣＵ１は、毎回決まった数のフレームを送信バッファ１２２にセットするようにしてもよいし、演算の処理経過状況に応じて、通信処理周期ごとにセットするフレーム数が変わるようにしてもよい。
【０１１３】
また、上述してきた実施例では、ＨＶ−ＥＣＵ１が、通信周期内において送信すべきデータを分割して送信する場合の例について説明したが、ＨＶ−ＥＣＵ１は、通信周期内において送信すべきデータを一括して送信することとしてもよい。
【０１１４】
かかる場合、ＨＶ−ＥＣＵ１からのデータのＣＡＮバスへの出力中に、モータＥＣＵ２からのデータがモータＥＣＵ２の送信バッファ２２２へ格納され、ＨＶ−ＥＣＵ１からのデータ出力が完了した時点で、モータＥＣＵ２からのデータ出力が開始されることとなる。したがって、ＨＶ−ＥＣＵ１が通信周期内において送信すべきデータを一括して送信する場合であっても、ＣＡＮバスに無駄な空き時間が生じることを防止することができる。
【０１１５】
また、上述してきた実施例では、マスタノードであるＨＶ−ＥＣＵ１からのデータの優先度が、スレーブノードであるモータＥＣＵ２からのデータの優先度よりも高く設定される場合の例について説明してきたが、これに限ったものではない。
【０１１６】
たとえば、ＨＶ−ＥＣＵ１が、通信周期内に送信すべきデータを一括して送信バッファ１２２へ格納し、モータＥＣＵ２が、開始ＩＤを含んだデータを受信してから所定時間計測したのちにデータの送信処理を開始する構成とする。かかる場合、モータＥＣＵ２からのデータの優先度をＨＶ−ＥＣＵ１からのデータの優先度よりも高く設定したとしても、ＨＶ−ＥＣＵ１からのデータ出力中に、モータＥＣＵ２からのデータが優先的にＣＡＮバスへ出力されることとなるため、ＣＡＮバスに無駄な空き時間を生じさせることなくデータ通信を行うことができる。
【０１１７】
また、上述してきた実施例では、ＨＶ−ＥＣＵ１およびモータＥＣＵ２がＣＡＮプロトコルに従って通信を行うこととしたが、ＨＶ−ＥＣＵ１およびモータＥＣＵ２は、ＣＡＮプロトコルと同様の通信調停を行う他の通信プロトコルに従って通信を行うこととしてもよい。また、ここでは、ＨＶ−ＥＣＵ１およびモータＥＣＵ２がＣＡＮバスを介して通信を行うこととしたが、ＣＡＮバスに類するものであれば他の通信線を用いてもよい。
【産業上の利用可能性】
【０１１８】
以上のように、本発明に係る通信システムは、安価な構成でデータ通信の効率を高めたい場合に有効であり、特に、車載ＥＣＵ間を相互に接続する車載ネットワークへの適用が考えられる。
【符号の説明】
【０１１９】
１    ＨＶ−ＥＣＵ（第１の通信装置）
１１    ＣＡＮトランシーバ
１２    マイコン
１２１    通信部
１２２    送信バッファ
１２３    受信バッファ
１２４    プラットフォーム
１２５    制御部
１２５ａ  データ格納処理部
１２５ｂ  受信完了処理部
２    モータＥＣＵ（第２の通信装置）
２１    ＣＡＮトランシーバ
２２    マイコン
２２１    通信部
２２２    送信バッファ
２２３    受信バッファ
２２４    プラットフォーム
２２５    制御部
２２５ａ  ＩＤ読取部
２２５ｂ  データ格納処理部
３    モータ
【図１】
0005409681.tif 000002
【図２】
0005409681.tif 000003
【図３】
0005409681.tif 000004
【図４】
0005409681.tif 000005
【図５】
0005409681.tif 000006
【図６】
0005409681.tif 000007
【図７】
0005409681.tif 000008
【図８】
0005409681.tif 000009
【図９】
0005409681.tif 000010
【図１０】
0005409681.tif 000011
【図１１】
0005409681.tif 000012