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