特許第5671388号(P5671388)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士通テン株式会社の特許一覧

<>
  • 特許5671388-通信システムおよび通信装置 図000002
  • 特許5671388-通信システムおよび通信装置 図000003
  • 特許5671388-通信システムおよび通信装置 図000004
  • 特許5671388-通信システムおよび通信装置 図000005
  • 特許5671388-通信システムおよび通信装置 図000006
  • 特許5671388-通信システムおよび通信装置 図000007
  • 特許5671388-通信システムおよび通信装置 図000008
  • 特許5671388-通信システムおよび通信装置 図000009
  • 特許5671388-通信システムおよび通信装置 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5671388
(24)【登録日】2014年12月26日
(45)【発行日】2015年2月18日
(54)【発明の名称】通信システムおよび通信装置
(51)【国際特許分類】
   H04L 12/28 20060101AFI20150129BHJP
   B60R 16/023 20060101ALI20150129BHJP
【FI】
   H04L12/28 200Z
   B60R16/02 665Z
【請求項の数】8
【全頁数】21
(21)【出願番号】特願2011-65652(P2011-65652)
(22)【出願日】2011年3月24日
(65)【公開番号】特開2012-204935(P2012-204935A)
(43)【公開日】2012年10月22日
【審査請求日】2014年1月16日
(73)【特許権者】
【識別番号】000237592
【氏名又は名称】富士通テン株式会社
(74)【代理人】
【識別番号】100089118
【弁理士】
【氏名又は名称】酒井 宏明
(72)【発明者】
【氏名】松井 貴志
(72)【発明者】
【氏名】▲高▼冨 伸一郎
【審査官】 羽岡 さやか
(56)【参考文献】
【文献】 特開2011−109452(JP,A)
【文献】 特開2011−040886(JP,A)
【文献】 特開2009−118113(JP,A)
【文献】 特開2009−253803(JP,A)
【文献】 国際公開第2010/073312(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 12/28−12/46
B60R 16/023
(57)【特許請求の範囲】
【請求項1】
第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムであって、
前記第1の通信装置は、
データの種別を表すID情報とデータの内容を表すデータ情報とを含んだフレームデータを前記第2の通信装置へ送信する第1の制御手段を備え、
前記第2の通信装置は、
前記第1の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う第2の制御手段を備え、
前記第2の制御手段は、
前記第1の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記第1の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから所定時間が経過するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しない
ことを特徴とする通信システム。
【請求項2】
前記所定時間は、前記所定のIDを含んだフレームデータを受信してから当該フレームデータを受信した通信周期が終了するまでの時間であることを特徴とする請求項に記載の通信システム。
【請求項3】
前記第2の制御手段は、
前記通信周期内に送信すべき全てのフレームデータを当該通信周期よりも前に取得するラッチ処理を併せて行うものであって、前記所定のIDを含んだフレームデータを受信してから所定時間が経過した後に前記所定のIDを含んだフレームデータを受信した場合であっても、前記ラッチ処理が完了していない場合には、前記送信処理を開始しないことを特徴とする請求項1または2に記載の通信システム。
【請求項4】
第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムであって、
前記第1の通信装置は、
データの種別を表すID情報とデータの内容を表すデータ情報とを含んだフレームデータを前記第2の通信装置へ送信する第1の制御手段を備え、
前記第2の通信装置は、
前記第1の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う第2の制御手段を備え、
前記第2の制御手段は、
前記第1の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記第1の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから前記通信周期内に送受信すべき全てのフレームデータの送受信が完了するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しない
ことを特徴とする通信システム。
【請求項5】
前記第2の制御手段は、
前記通信周期内に送信すべき全てのフレームデータを当該通信周期よりも前に取得するラッチ処理を併せて行うものであって、前記所定のIDを含んだフレームデータを受信してから前記通信周期内に送受信すべき全てのフレームデータの送受信が完了した後に、前記所定のIDを含んだフレームデータを受信した場合であっても、前記ラッチ処理が完了していない場合には、前記送信処理を開始しないことを特徴とする請求項に記載の通信システム。
【請求項6】
前記第1の制御手段は、
前記通信周期において送信すべきフレームデータのうち、前記所定のIDを含んだフレームデータを最初に送信することを特徴とする請求項1〜の何れか一つに記載の通信システム。
【請求項7】
第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムにおける通信装置であって、
他の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う制御手段を備え、
前記制御手段は、
前記他の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記他の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから所定時間が経過するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しない
ことを特徴とする通信装置。
【請求項8】
第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムにおける通信装置であって、
他の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う制御手段を備え、
前記制御手段は、
前記他の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記他の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから前記通信周期内に送受信すべき全てのフレームデータの送受信が完了するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しない
ことを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、通信装置間で通信を行う通信システムおよび通信装置に関する。
【背景技術】
【0002】
従来、エンジンECU(Electronic Control Unit)やモータECUなどの電子制御ユニット間の通信方式として、CAN(Controller Area Network)通信が知られている。CAN通信は、電子制御ユニット間で送受信される各種の命令や制御の伝送をCANバスと呼ばれる通信線を用いて行うものであり、安価で自由度の高い通信方式として広く利用されている。
【0003】
また、CAN通信では、マスタやスレーブといった主従関係を決めず、それぞれの電子制御ユニットが任意の通信タイミングでデータの送信を行う所謂マルチマスタ方式が採用されている。
【0004】
ところで、通信方式の一つとして、通信装置間に主従関係を設けて通信を行うシングルマスタ方式も知られている。かかるシングルマスタ方式では、ネットワーク内の1つの電子制御ユニットがマスタノードとなって通信スケジュールを管理し、他の電子制御ユニット(スレーブノード)は、マスタノードからの要求に従ってデータ送信等を行う。
【0005】
たとえば、特許文献1に記載の技術では、マスタノードが、特定のスレーブノードに対してデータ送信を行う場合に、送信先スレーブ情報を最初に送信する。また、各スレーブノードは、送信先スレーブノード情報を参照し、自装置宛のものであると判定した場合に、その後に送信されてくるデータに基づいて所定の演算処理を行い、演算結果をマスタノードへ送信する。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2004−362067号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、特許文献1に記載の技術には、データ通信の効率を高めるという点でさらなる改善の余地があった。たとえば、特許文献1に記載の技術では、送信先スレーブ情報を演算処理用のデータとは別に送信することとしている。したがって、送信先スレーブ情報を送信する分だけデータ量が増えるため、データ通信の効率が低下することとなる。
【0008】
このようにデータ通信の効率が低下すると、特に、マスタノードおよびスレーブノード間で所定の制御周期ごとにデータの送受信を繰り返す場合に、データの送受信を制御周期内に完了させることができないおそれがある。
【0009】
開示の技術は、上述した従来技術による問題点を解消するためになされたものであり、データ通信の効率を高めることができる通信システムおよび通信装置を提供することを目的とする。
【課題を解決するための手段】
【0010】
本願は、第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムであって、前記第1の通信装置は、データの種別を表すID情報とデータの内容を表すデータ情報とを含んだフレームデータを前記第2の通信装置へ送信する第1の制御手段を備え、前記第2の通信装置は、前記第1の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う第2の制御手段を備え、前記第2の制御手段は、前記第1の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記第1の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから所定時間が経過するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しないことを特徴とする。
【0011】
また、本願は、第1の通信装置および第2の通信装置が所定の通信周期でデータの送受信を行う通信システムにおける通信装置であって、他の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う制御手段を備え、前記制御手段は、前記他の通信装置から受信したフレームデータのID情報が所定のIDであった場合には、当該受信したフレームデータのデータ情報を用いて前記演算処理を行うとともに、前記通信周期内に送信すべきフレームデータの前記他の通信装置への送信処理を開始するものであって、前記所定のIDを含んだフレームデータを受信してから所定時間が経過するまでの間に、前記所定のIDを含んだフレームデータを受信しても前記送信処理を開始しないことを特徴とする。
【発明の効果】
【0012】
本願によれば、データ通信の効率を高めることができるという効果を奏する。
【図面の簡単な説明】
【0013】
図1図1は、本願に係る通信手法の概要を示す図である。
図2図2は、本実施例に係る通信システムの構成例を示す図である。
図3図3は、HV−ECUおよびモータECUの構成を示すブロック図である。
図4図4は、所定の通信周期におけるHV−ECUおよびモータECUの通信タイミングの一例を示すタイミングチャートである。
図5図5は、通信周期内に同期用データが複数送信された場合の対策例(その1)を示す図である。
図6図6は、通信期内に同期用データが複数送信された場合の対策例(その2)を示す図である。
図7図7は、通信周期内に同期用データが複数送信された場合の対策例(その3)を示す図である。
図8図8は、モータECUが実行する処理手順の一例を示すフローチャート(その1)である。
図9図9は、モータECUが実行する処理手順の一例を示すフローチャート(その2)である。
【発明を実施するための形態】
【0014】
以下に添付図面を参照して、本発明に係る通信システムおよび通信装置の実施例を詳細に説明する。まず、実施例の詳細な説明に先立ち、本願に係る通信手法の概要について図1を用いて説明する。図1は、本願に係る通信手法の概要を示す図である。
【0015】
図1に示すように、本願に係る通信手法では、第1の通信装置と第2の通信装置とが所定の通信周期でデータの送受信を行う。具体的には、第1の通信装置はマスタノードであり、第2の通信装置との通信スケジュールを管理する。また、第2の通信装置はスレーブノードであり、マスタノードである第1の通信装置からの指示に従ってデータ送信等を行う。
【0016】
より具体的には、本願に係る通信手法では、第1の通信装置が、第2の通信装置に対して同期用データを送信する。そして、第2の通信装置は、同期用データを受信したことを契機として、通信周期内に送信すべきデータの送信処理を開始する。
【0017】
ここで、同期用データとは、通信周期の開始を示す所定のID(以下、「同期用ID」と記載する)を含んだフレームデータである。なお、フレームデータには、少なくとも、データの種別を表すID情報とデータの内容を表すデータ情報とが含まれる。
【0018】
第2の通信装置は、第1の通信装置からフレームデータを受信した場合に、受信したフレームデータに含まれるIDを読み取り、読み取ったIDが同期用IDであれば、通信周期内に送信すべきフレームデータの送信処理を開始する。
【0019】
また、第2の通信装置は、第1の通信装置から送信されるフレームデータに基づいて所定の演算処理を行う。具体的には、第2の通信装置は、第1の通信装置からフレームデータを受信すると、受信したフレームデータに含まれるデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、かかるデータ情報を用いて所定の演算処理を行う。
【0020】
ここで、図1の(A)に示すように、同期用データを演算処理用のフレームデータ(以下、「演算用データ」と記載する)とは別に設けることとすると、同期用データを送信する分だけデータ量が増え、データ通信の効率が低下する。データ通信の効率が低下すると、フレームデータの送受信を通信周期内に完了させることができない確率が高くなるため、好ましくない。
【0021】
このため、本願に係る通信手法では、図1の(B)に示すように、同期用データを演算用データとして兼用することとした。すなわち、本願に係る通信手法では、同期用データに含まれる同期用IDを送信処理の開始を示す情報として用い、同期用データのデータ情報を演算用データとして用いることとした。
【0022】
このように、本願に係る通信手法では、第1の通信装置が、データの種別を表すID情報とデータの内容を表すデータ情報とを含んだフレームデータを第2の通信装置へ送信し、第2通信装置が、第1の通信装置からフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う。
【0023】
また、第2の通信装置が、第1の通信装置から受信したフレームデータのID情報が同期用IDであった場合に、当該受信したフレームデータのデータ情報を用いて演算処理を行うとともに、通信周期内に送信すべきフレームデータの第1の通信装置への送信処理を開始することとした。
【0024】
したがって、同期用データを演算用データとは別に設ける場合と比較して、第1の通信装置から第2の通信装置へ送信されるフレームデータのデータ量が少なくなるため、データ通信を効率よく行うことができる。
【0025】
ところで、第1の通信装置からの送信データにデータ化け等が生じることによって、同期用データが、1つの通信周期内で複数回送信される可能性がある。このような場合、第2の通信装置は、同期用データを受信するごとに、通信周期内において送信すべきフレームデータの送信処理を開始し直すこととなる。
【0026】
1つの通信周期内で送信処理が複数回再開されると、第1の通信装置への送信データを通信周期内に送信しきれなくなる可能性があり、また、送信しきれた場合であっても、通信周期内に同じ種類のフレームデータが複数回送られてきている可能性が高いので、第1の通信装置での処理に問題が生じる可能性があり、好ましくない。
【0027】
このため、本願に係る通信手法では、所定の条件を満たしていない場合には、同期用データを受信した場合であっても送信処理を開始しないようにした。このようにすることで、第2の通信装置が不適切なタイミングで送信処理を開始してしまうことを防止することができる。なお、かかる点については、実施例において後述することとする。
【0028】
以下では、本願に係る通信手法を適用した通信システムおよび通信装置についての実施例を詳細に説明する。なお、以下の実施例では、通信システムの一例として、車載ECU間の通信システムを用いて説明するが、これに限定されるものではなく、本願に係る通信手法は、他の通信装置間の通信システムにも適用可能である。また、以下では、パワートレイン系ECUを制御するHV−ECU(Hybrid Vehicle−ECU)を第1の通信装置の一例とし、パワートレイン系ECUの一つであるモータECUを第2の通信装置の一例として説明する。
【実施例1】
【0029】
まず、実施例1に係る通信システムの構成例について図2を用いて説明する。図2は、実施例1に係る通信システムの構成例を示す図である。
【0030】
図2に示すように、本実施例に係る通信システムでは、HV−ECU1とモータECU2とが、CANバスを介して相互に接続される。CANバスは、CAN_HiラインおよびCAN_Loラインからなる2線式の通信線である。また、モータECU2には、モータ3が接続されている。
【0031】
かかる通信システムでは、マスタノードであるHV−ECU1が、モータECU2等の車両に設けられた各種ECUと連携してモータ3やエンジン等の全体的な制御を行い、スレーブノードであるモータECU2が、HV−ECU1からの命令に従ってモータ3の具体的な制御を行う。
【0032】
たとえば、HV−ECU1は、モータ3のトルク指令値をCANバス経由でモータECU2へ送信する。また、モータECU2は、HV−ECU1からCANバス経由でトルク指令値を受信すると、受信したトルク指令値に基づいてモータ3の制御を行う。また、モータECU2は、モータ3への制御結果をHV−ECU1へ送信する。かかる一連の処理はあらかじめ決められた所定の通信周期内で行われる。
【0033】
HV−ECU1は、CANトランシーバ11とマイコン12とを備える。また、モータECU2も同様に、CANトランシーバ21とマイコン22とを備える。ここで、CANトランシーバ11,21、マイコン12,22内のハードウェア部、CANバスといったハードウェアは、CAN通信用のハードウェアをそのまま流用したものである。すなわち、本実施例に係る通信システムは、CAN通信と同様、安価な構成を用いて実現することが可能である。
【0034】
なお、図2に示すように、HV−ECU1は、モータECU2と接続するためのCANバスとは別に、たとえばエンジンECU4や電池ECU5といった車両に設けられた様々なECUと接続するためのバス(たとえば、CANバス)とも接続する。
【0035】
また、図2に示すように、HV−ECU1とモータECU2とを接続するCANバスには、HV−ECU1およびモータECU2のみが接続されるものとするが、CANバスには3つ以上の通信装置(ECU)を接続することも可能である。
【0036】
次に、HV−ECU1およびモータECU2の構成について図3を用いて説明する。なお、図3では、HV−ECU1およびモータECU2の特徴を説明するために必要な構成要素のみを示しており、一般的な構成要素についての記載を省略している。
【0037】
図3に示すように、HV−ECU1は、CANトランシーバ11およびマイコン12を備える。マイコン12は、通信部121と、送信バッファ122と、受信バッファ123と、プラットフォーム124と、制御部125とを備える。また、制御部125は、データ格納処理部125aと、受信完了処理部125bとを備える。
【0038】
また、モータECU2は、CANトランシーバ21と、マイコン22とを備える。また、マイコン22は、通信部221と、送信バッファ222と、受信バッファ223と、プラットフォーム224と、制御部225とを備える。また、制御部225は、ID読取部225aと、データ格納処理部225bと、演算処理部225cとを備える。
【0039】
まず、HV−ECU1の構成について説明する。CANトランシーバ11は、マイコン12およびCANバス間のインタフェース用IC(Integrated Circuit)である。具体的には、CANトランシーバ11は、マイコン12で生成されたフレームデータをCANバスへ出力するとともに、CANバスから入力されたデータをマイコン12へ出力する。
【0040】
マイコン12は、モータECU2との間の通信をCANプロトコルに従って制御するマイクロコンピュータである。ここで、かかるマイコン12のうち、通信部121、送信バッファ122、受信バッファ123は、ハードウェアで構成され、プラットフォーム124および制御部125は、ソフトウェアで構成される。
【0041】
通信部121は、フレームデータの送受信をCANプロトコルに従って実行するハードウェア部である。具体的には、通信部121は、送信バッファ122にフレームデータが格納された場合に、かかる送信バッファ122に格納されたフレームデータをCANプロトコルに従ってCANトランシーバ11経由でCANバスへ出力する。
【0042】
具体的には、通信部121は、CANバスに対してフレームデータを出力する際に、CANバスの使用状況を確認し、CANバスが使用されていなければ、CANバスへのフレームデータの出力を実行する。また、通信部121は、CANバスの競合が発生した場合には、相手側(ここでは、モータECU2)が送信しようとしているフレームデータの優先順位と自装置が送信しようとしているフレームデータの優先順位とを比較する。そして、自装置が送信しようとしているフレームデータの優先順位が高ければ、相手側よりも先にCANバスへのフレームデータ出力を行う。
【0043】
一方、相手側のフレームデータの優先度が高ければ、相手側のフレームデータの出力を優先させ、CANが空き状態となったのちにCANバスへのフレームデータの出力を行う。なお、このような処理は「通信調停」と呼ばれる。
【0044】
また、通信部121は、CANトランシーバ11からデータを受け取った場合には、受け取ったフレームデータを受信バッファ123へ格納する。
【0045】
送信バッファ122は、他のECU(ここでは、モータECU2)に対して送信すべきフレームデータを一時的に記憶するハードウェア部である。また、受信バッファ123は、他のECU(ここでは、モータECU2)から受信したフレームデータを一時的に記憶するハードウェア部である。
【0046】
なお、CANトランシーバ11、通信部121、送信バッファ122、受信バッファ123は、従来のCAN通信で用いられるCANトランシーバ、通信部、送信バッファ、受信バッファを流用することができるが、これに限ったものではない。すなわち、本実施例に係る通信システム専用のトランシーバ、通信部、送信バッファ、受信バッファを用いてもよい。
【0047】
プラットフォーム124は、ソフトウェア部である制御部125によって生成されたフレームデータをハードウェア部である送信バッファ122へ渡す処理を行う処理部である。また、プラットフォーム124は、ハードウェア部である受信バッファ123から受け取ったフレームデータをソフトウェア部である制御部125へ渡す処理を行う処理部でもある。
【0048】
制御部125は、たとえばCPU(Central Processing Unit)であり、モータECU2との通信に関する処理等を実行するソフトウェア部である。かかる制御部125は、特に、データ格納処理部125aと、受信完了処理部125bとを備える。
【0049】
データ格納処理部125aは、モータECU2への送信データをプラットフォーム124経由で送信バッファ122へ格納する処理部である。具体的には、データ格納処理部125aは、モータECU2へ送信すべき全フレームデータを所定のブロック(たとえば、4フレームごと)に分割し、かかる分割データの各フレームデータを通信処理周期ごとに送信バッファ122へ格納する。
【0050】
ここで、HV−ECU1およびモータECU2間で送受信されるフレームデータのフレーム構成について説明しておく。各フレームデータには、データの内容を表す0〜8Byteのデータ情報が含まれる。また、各フレームには、ID情報が含まれる。かかるIDは、たとえば11Bitであらわされる情報であり、データの種別および優先順位を示す。本実施例に係る通信手法では、かかるID情報のうちの特定のIDを同期用IDとして用いる。なお、各フレームには、SUMチェックに用いられるSUM値等も格納される。
【0051】
受信完了処理部125bは、モータECU2から所定の通信周期内における最終のフレームデータを受信した場合に、受信完了処理を行う処理部である。たとえば、受信完了処理部125bは、モータECU2から最終のフレームデータを受信すると、サムチェックを実施し、モータECU2から全てのフレームデータを正常に受信できたか否かを判定する。
【0052】
なお、図3では、制御部125が備える処理部として、データ格納処理部125aおよび受信完了処理部125bのみを示したが、制御部125は、モータECU2から受信したフレームデータを用いて所定の演算を行う演算処理部などの他の処理部を備えていてもよい。
【0053】
次に、モータECU2の構成について説明する。なお、モータECU2のハードウェア、具体的には、CANトランシーバ21、通信部221、送信バッファ222および受信バッファ223は、HV−ECU1のハードウェアと同一構成であるため、ここでの説明は省略する。また、プラットフォーム224についても、HV−ECU1のプラットフォーム124と同様の処理部であるため、ここでの説明は省略する。
【0054】
モータECU2の制御部225は、たとえばCPUであり、HV−ECU1との通信に関する処理等を実行するソフトウェア部である。かかる制御部225は、ID読取部225a、データ格納処理部225b、演算処理部225cなどを備える。
【0055】
ID読取部225aは、受信バッファ223へ格納されたフレームデータのIDを読み取り、読み取ったIDが同期用IDである場合に、かかる同期用IDをデータ格納処理部225bへ渡す処理を行う処理部である。ここで、どのIDが同期用IDであるかは、あらかじめ決められているものとする。
【0056】
データ格納処理部225bは、HV−ECU1への送信データをプラットフォーム224経由で送信バッファ222へ格納する処理である送信処理を行う処理部である。データ格納処理部225bは、ID読取部225aから同期用IDを受け取ると、かかる送信処理を開始する。具体的には、データ格納処理部225bは、同期用IDに対応するフレームデータ、すなわち、所定の通信周期内に送信すべきフレームデータを所定ブロックごとに送信バッファ222へ格納する処理を行う。
【0057】
このように、スレーブノードであるモータECU2は、マスタノードであるHV−ECU1から同期用IDを含んだフレームデータ(同期用データ)を受信した場合に、通信周期内に送信すべきフレームデータの送信処理を開始することとした。
【0058】
すなわち、モータECU2は、HV−ECU1から同期用データを受信することで、通信周期の開始タイミングを把握する。そして、かかる開始タイミングでHV−ECU1への送信データの送信を開始することで、モータECU2は、HV−ECU1への送信データを通信周期内においてより確実に送信し終えることが可能となる。
【0059】
演算処理部225cは、通信周期内においてHV−ECU1から受信したフレームデータ、すなわち、同期用データを含む複数のフレームデータを用いて所定の演算処理を行う処理部である。たとえば、演算処理部225cは、HV−ECU1からトルク指令値を受信した場合には、受信したトルク指令値に基づいてモータ3の制御量を演算する。
【0060】
このように、演算処理部225cは、同期用データを含む複数のフレームデータを演算用データとして用いて所定の演算処理を行うこととした。これにより、同期用データを演算用データとは別に設ける場合と比較して少なくて済むため、データ通信を効率よく行うことができる。データ通信の効率が高まれば、HV−ECU1への送信データを通信周期内に送信しきれない事態が発生する確率を下げることができ、データ通信の信頼性を高めることができる。
【0061】
ここで、所定の通信周期におけるHV−ECU1およびモータECU2の通信タイミングについて図4を用いて説明する。図4は、所定の通信周期におけるHV−ECU1およびモータECU2の通信タイミングの一例を示すタイミングチャートである。
【0062】
ここで、図4では、HV−ECU1およびモータECU2の通信処理周期がそれぞれ1msであり、通信周期が8周期分の通信処理周期に相当する8msであるものとする。また、図4では、HV−ECU1とモータECU2との間で、制御周期の開始・終了タイミングの同期を取ることなく、通信処理周期および制御周期の長さのみを同じ長さに設定する場合の例を示している。
【0063】
ここで、「制御周期」とは、第1の通信装置で行われる所定の制御処理の処理周期のことであり、またここでは、所定の制御処理のために必要な、第1の通信装置および第2の通信装置間で行われる通信処理を完了させる必要がある期間のことでもある。「通信処理周期」とは、通信周期内に通信のために行う処理の処理周期である。なお、以下では、制御周期が通信周期と同じである場合の例について説明するが、制御周期は、通信周期と周期の長さや開始タイミングが異なってもよい。
【0064】
図4に示すように、HV−ECU1の制御部125は、通信周期が到来すると、前回の通信周期において取得したフレームデータを取得しラッチ(保持)するラッチ処理や今回の通信周期において送信したいデータのSUM値を算出する処理を行う(図4の(1a)参照)。ここで、SUM値とは、各フレームデータのうちSUM値を除いた情報(IDやデータ等)を0および1の2進数であらわした情報とした場合に、その値を全て足し合わせた値である。算出されたSUM値は、各フレームデータに付加されることとなる。
【0065】
また、HV−ECU1の制御部125は、かかる処理を終えたのち、モータECU2へ送信するデータの分割データのうち、最初の分割データを送信バッファ122へ格納する(図4の(1b)参照)。
【0066】
かかる分割データの先頭のフレームデータ100には、同期用IDが含まれている。すなわち、HV−ECU1は、通信周期において送信すべきフレームデータのうち、同期用データを最初に送信する。これにより、モータECU2は、通信周期内に送信すべきフレームデータの送信処理を通信周期における早い段階で開始することができ、HV−ECU1への送信データを通信周期内に送信しきれない事態をより確実に防止することができる。
【0067】
HV−ECU1の送信バッファ122に分割データが格納されると、HV−ECU1の通信部121は、送信バッファ122に格納された分割データをCANバスへ出力する(図4の(1c)参照)。CANバスへ出力された分割データは、モータECU2の通信部221へ入力され、かかる通信部221によって受信バッファ223へ格納される。
【0068】
また、HV−ECU1では、制御部125が、残りの分割データを通信処理周期ごとに送信バッファ122へ格納していき、通信部121が、送信バッファ122へ格納されたフレームデータをCANプロトコルに従って出力していく。
【0069】
なお、HV−ECU1は、今回の制御周期が開始されると、前回の制御周期(通信周期)においてモータECU2から送られてきていた、モータ回転数といったモータの状態に関する情報等や、別のバスから送られてくる運転者のアクセルの踏み込み状態(運転者が求めているトルク量)、電池の充電状態等の車両制御に関する各種情報に基づいて、モータやエンジンで出力する必要があるトルク量(トルク指令値)等を算出する演算処理を行う。
【0070】
モータECU2の制御部225は、受信バッファ223に分割データが格納されると、受信割り込みを発生させ、受信バッファ223に格納された分割データのIDを読み取る(図4の(2a)参照)。このとき、モータECU2の制御部225は、読み取ったIDに同期用IDが含まれていれば、通信周期(HV−ECU1の制御周期)内に送信すべきフレームデータの送信処理を開始する。具体的には、同期用IDに対応するデータを所定ブロックに分割し、各分割データを通信処理周期ごとに送信バッファ222へ格納する処理を開始する(図4の(2b)参照)。
【0071】
なお、送信バッファ222に分割データが格納されると、モータECU2の通信部221は、送信バッファ222に格納された分割データをCANバスへ出力する(図4の(2c)参照)。CANバスへ出力された分割データは、HV−ECU1の通信部121へ入力され、かかる通信部121によって受信バッファ123へ格納される。
【0072】
また、モータECU2では、制御部225が、残りの分割データを通信処理周期ごとに送信バッファ222へ格納していき、通信部221が、送信バッファ222へ格納されたフレームデータをCANプロトコルに従って出力していく。
【0073】
なお、モータECU2は、HV−ECU1から同期用IDを受信すると、取得した現在のモータ回転数といったモータの状態(前回の通信周期で、HV−ECU1から送られてきたトルク指令値等に基づいてモータを制御した後のモータの状態)に関する情報や、前回の制御周期におけるモータECU2での演算結果のうち、HV−ECU1に送信する必要があるデータ等を送信バッファ222に格納する処理を開始する。
【0074】
一方、HV−ECU1の制御部125は、通信周期内に受信すべきフレームデータのうち最終のフレームデータをモータECU2から受信すると、受信完了処理を実行する(図4の(1d)参照)。具体的には、HV−ECU1では、受信完了処理部125bが、通信周期内に受信したフレームデータのSUM値を算出し、算出したSUM値をモータECU2から送信されたSUM値と比較することで、かかるSUM値が正常であるか否かのサムチェックを行う。
【0075】
なお、ここでは、1つの通信周期で受信した全てのフレームデータのSUMチェックをまとめて行う場合の例を示したが、これに限らず、フレームデータを受信するごとにSUMチェックを実行することとしてもよい。
【0076】
また、モータECU2の制御部225も同様に、通信周期内に受信すべきフレームデータのうち最終のフレームデータをHV−ECU1から受信すると、受信完了処理を実行する(図4の(2d)参照)。
【0077】
また、モータECU2のデータ格納処理部225bは、通信周期内における任意のタイミングで、次の通信周期において送信すべき全てのフレームデータを取得しラッチ(保持)するラッチ処理やラッチしたデータのSUM値を算出する処理を行う(図4の(2e)参照)。
【0078】
すなわち、データ格納処理部225bは、通信周期内に送信すべき全てのフレームデータをかかる通信周期よりも前に取得しておき、HV−ECU1から同期用データを受信した場合に、取得しておいたフレームデータの送信処理を開始する。
【0079】
なお、データ格納処理部225bがラッチ処理を行うタイミングは、前回の通信周期で送信する必要がある全てのフレームデータの送信が完了してから、次の通信周期での送信が開始されるまでの間における任意のタイミングが望ましい。たとえば、データ格納処理部225bがラッチ処理を行うタイミングは、通信周期内に送信する最後のデータの送信完了時や、モータECU2が定期的に実行する制御処理(モータECU1の制御周期)の開始時や終了時などである。
【0080】
ところで、本実施例に係る通信システムでは、同期用IDを通信周期の開始時に1回だけ送信することとしている。ところが、たとえばHV−ECU1からの送信データにデータ化け等が発生した場合には、同期用IDを含んだフレームデータが通信周期内に複数回送信される可能性がある。
【0081】
このような場合には、モータECU2が、同期用IDを受け取るごとに通信周期内において送信すべきフレームデータの送信処理を開始し直してしまう結果、HV−ECU1への送信データを通信周期内に送信しきれなくなるおそれがある。
【0082】
そこで、本実施例に係る通信システムでは、所定の条件を満たしていない場合には、モータECU2が同期用IDを受け取ったとしても送信処理を開始しないようにした。以下に、通信周期内に同期用データが複数送信された場合の対策例について説明する。
【0083】
図5は、通信周期内に同期用データが複数送信された場合の対策例(その1)を示す図である。なお、図5では、同期用データが各通信周期の開始時において正常に送信される一方で、同期用ID以外のIDが同期用IDにデータ化けした同期用データが通信周期の途中で異常送信された場合の例を示している。
【0084】
図5に示すように、モータECU2は、同期用データを受信してから所定時間が経過するまでの間に同期用データを再度受信した場合には、送信処理を開始しないようにしてもよい。
【0085】
具体的には、モータECU2のデータ格納処理部225bは、HV−ECU1から同期用データを受信すると、送信処理を開始する(図5の(1)参照)。また、データ格納処理部225bは、同期用データを受信すると、所定時間を計時するタイマを起動し、内部時計を用いて所定時間を計時する計時処理を開始する(図5の(2)参照)。
【0086】
そして、モータECU2は、かかる計時処理が終了するまでの期間を同期禁止期間とし、かかる同期禁止期間内に同期用データを受信したとしても、送信処理の開始を行わない。
【0087】
具体的には、データ格納処理部225bは、ID読取部225aから同期用IDを受け取った場合に、所定の条件(ここでは、同期用データを受信してから所定時間が経過したこと)を満たしているか否か判定する。そして、所定の条件を満たしていない場合、すなわち、同期禁止期間内である場合には、ID読取部225aから受け取った同期用IDを破棄する(図5の(3)参照)。
【0088】
このように、データ格納処理部225bは、同期用データを受信してから所定時間が経過するまでの間は、所定の条件を満たしていないと判定し、送信処理を開始しないこととした。
【0089】
これにより、モータECU2が同期用データを不適切なタイミングで受け取ったとしても、送信処理が開始されることはない。したがって、モータECU2が送信処理を開始し直すことでHV−ECU1への送信データを通信周期内に送信しきれなくなるといった事態を防止することができる。
【0090】
一方、データ格納処理部225bは、同期禁止期間が終了していれば、HV−ECU1から同期用データを受信したことを契機として送信処理および計時処理を開始することとなる(図5の(4)参照)。
【0091】
なお、図5では、正常送信された同期用データを受信してからかかる同期用データを受信した通信周期が終了するまでの時間としてあらかじめ予測される時間を所定時間としている。具体的には、通信周期が開始してからモータECU2が同期用データを受信するまでのタイムラグを、通信周期の1周期に相当する時間から差し引いた時間を所定時間とする。
【0092】
このようにすれば、通信周期が終了するまでの間に異常送信された全ての同期用データの同期用IDを破棄することができる。すなわち、正常送信された同期用データのみに基づいて送信処理を開始することができる。
【0093】
ただし、所定時間は、これに限ったものではない。たとえば、所定時間は、HV−ECU1およびモータECU2間のデータ送受信が完了するまでの時間を考慮して決定してもよい。
【0094】
たとえば、図4に示した場合の例では、通信周期は8msであるが、フレームデータの送受信は7msで完了している。このような場合には、同期禁止期間が7msで終了するように所定時間を設定してもよい。なお、フレームデータの送受信に要する時間は既知であるものとする。また、所定時間は、たとえば通信周期の1周期分に相当する時間であってもよい。
【0095】
また、モータECU2は、同期用データを受信してから通信周期内に送受信すべき全てのフレームデータの送受信が完了するまでの間に、同期用データを受信したとしても送信処理を開始しないようにしてもよい。以下では、かかる点について図6を用いて説明する。図6は、通信周期内に同期用データが複数送信された場合の対策例(その2)を示す図である。
【0096】
図6に示すように、モータECU2は、同期用データを受信済みであることを示す受信済フラグの状態に応じて同期禁止期間を決定する。具体的には、モータECU2のデータ格納処理部225bは、HV−ECU1から同期用データを受信すると、送信処理を開始するとともに(図6の(1)参照)、受信済フラグをOFFする。
【0097】
また、データ格納処理部225bは、HV−ECU1から通信周期における最終のフレームデータを受信した場合に、受信完了処理を実行するとともに(図6の(2)参照)、受信済フラグをONする。
【0098】
なお、ここでは、モータECU2が、HV−ECU1から最終のフレームデータを受信する前に、HV−ECU1への送信データを全て送信し終えているものとする。すなわち、モータECU2は、HV−ECU1へのデータ送信が完了し、かつ、HV−ECU1からのデータ受信が完了した場合に、受信済フラグをONする。HV−ECU1からのデータ受信が完了した時点で、HV−ECU1へのデータ送信が完了していない場合には、HV−ECU1へのデータ送信が完了した時点で受信済フラグをONすればよい。
【0099】
なお、HV−ECU1へのデータ送信が完了していない場合でも、HV−ECU1からのデータ受信が完了した時点で受信済フラグをONするように構成してもよい。
【0100】
データ格納処理部225bは、受信済フラグがOFFされている期間を同期禁止期間とし、かかる同期禁止期間内に同期用データが異常送信されたとしても、送信処理の開始を行わない。
【0101】
具体的には、データ格納処理部225bは、ID読取部225aから同期用IDを受け取った場合に、所定の条件(ここでは、受信済フラグがONであること)を満たしているか否か判定する。そして、所定の条件を満たしていない場合、すなわち、受信済フラグがOFFである場合には、ID読取部225aから受け取った同期用IDを破棄する(図6の(3)参照)。
【0102】
一方、データ格納処理部225bは、同期禁止期間が終了していれば、HV−ECU1から同期用データを受信したことを契機として送信処理を開始し(図6の(4)参照)、受信済フラグをOFFする。
【0103】
このように、データ格納処理部225bは、同期用データを受信してから通信周期内に送受信すべき全てのフレームデータの送受信が完了するまでの間は、所定の条件を満たしていないと判定し、同期用データを受信したとしても送信処理を開始しないこととした。
【0104】
したがって、通信周期内におけるフレームデータの送受信が完了するまでの間に、同期用データを再度受け取った場合に、送信処理が開始されることを防止することができる。この結果、モータECU2が送信処理を開始し直すことでHV−ECU1への送信データを通信周期内に送信しきれなくなるといった事態を防止することができる。
【0105】
なお、ここでは、フラグ(受信済フラグ)を用いて同期禁止期間を決定することとしたが、これに限らず、カウンタを用いて同期禁止期間を決定してもよい。すなわち、データ格納処理部225bは、同期用データを受信した場合にカウンタをカウントアップし、通信周期内のデータ送受信が完了した場合にカウンタをリセットする。そして、データ格納処理部225bは、カウンタがカウントアップされている期間を同期禁止期間として決定すればよい。
【0106】
ところで、図6に示したように同期禁止期間が通信周期よりも早く終了するようにした場合、同期禁止期間が終了してから通信周期が終了するまでの間に同期用データが異常送信されたとしても、かかる同期用データに基づいて送信処理が開始されることとなる。
【0107】
このとき、次の通信周期において送信すべきフレームデータのラッチ処理が完了している場合は、この通信周期のみ、モータECU2からの送信開始タイミングが早まるだけなので特に問題ないが、次の通信周期において送信すべきフレームデータのラッチ処理が完了していないと、今回の通信周期において送信したフレームデータと同一のデータがHV−ECU1に対して送信されることとなるため、好ましくない。
【0108】
そこで、モータECU2は、次の通信周期において送信すべきフレームデータのラッチ処理が完了したか否かをさらに考慮して同期禁止期間を決定することとしてもよい。以下では、かかる点について図7を用いて説明する。図7は、通信周期内に同期用データが複数送信された場合の対策例(その3)を示す図である。
【0109】
図7に示すように、モータECU2は、受信済フラグの状態に加え、ラッチ処理が完了済みであることを示すラッチフラグの状態をさらに考慮して同期禁止期間を決定する。具体的には、モータECU2のデータ格納処理部225bは、HV−ECU1から同期用データを受信すると、送信処理を開始する(図7の(1)参照)。また、データ格納処理部225bは、同期用データを受信すると、受信済フラグをOFFするとともに、ラッチフラグをOFFする。
【0110】
また、データ格納処理部225bは、HV−ECU1から通信周期における最終のフレームデータを受信すると、受信完了処理を実行するとともに(図7の(2)参照)、受信済フラグをONする。なお、図6と同様に、モータECU2は、HV−ECU1から最終のフレームデータを受信する前に、HV−ECU1への送信データを全て送信し終えているものとする。
【0111】
さらに、データ格納処理部225bは、ラッチ処理が完了すると(図7の(3)参照)、ラッチフラグをONする。そして、データ格納処理部225bは、受信済フラグがOFFされている期間またはラッチフラグがOFFされている期間のうち終了が遅い方の期間を同期禁止期間とし、かかる同期禁止期間内に同期用データが異常送信されたとしても、送信処理の開始を行わない。
【0112】
具体的には、データ格納処理部225bは、ID読取部225aから同期用IDを受け取った場合に、所定の条件(ここでは、受信済フラグがONかつラッチフラグがONであること)を満たしているか否か判定する。そして、所定の条件を満たしていない場合には、ID読取部225aから受け取った同期用IDを破棄する。
【0113】
一方、データ格納処理部225bは、所定の条件を満たしている場合、すなわち、受信済フラグがONかつラッチフラグがONである場合には、同期用データが異常送信されたものであったとしても、かかる同期用データを受信したことを契機として送信処理を開始する(図7の(4)参照)。
【0114】
かかる場合、1つの通信周期において送信処理の開始が2回行われることとなるが、今回の通信周期におけるフレームデータの送受信が完了しており、かつ、次の通信周期で送信すべきフレームデータのラッチ処理も完了しているため問題はない。
【0115】
なお、図7に示した場合には、異常送信された同期用データを受信した時点で、受信済フラグがOFFされるとともにラッチフラグがOFFされることとなる。したがって、データ格納処理部225bは、次の通信周期の開始時に正常送信された同期用データを受信したとしても、かかる同期用データに含まれる同期用IDを破棄する(図7の(5)参照)が、この通信周期のみ、モータECU2からの送信開始タイミングが早まるだけなので特に問題ない。
【0116】
このように、データ格納処理部225bは、所定の条件(ここでは、受信済フラグがONであること)を満たした場合であっても、ラッチ処理が完了していない場合には、同期用データを受信しても送信処理を開始しないこととした。
【0117】
このため、次の通信周期において送信すべきフレームデータのラッチ処理が完了する前に同期用データを受信することによって、今回の通信周期において送信したフレームデータと同一のデータが次の通信周期でも送信されるといった事態を防止することができる。
【0118】
なお、ここでは、受信済フラグがONであることを所定の条件とする場合の例に対してラッチフラグを適用したが、同期用データを受信してから所定時間が経過したことを所定の条件とする場合の例に対してラッチフラグを適用することも可能である。
【0119】
かかる場合、データ格納処理部225bは、同期用データを受信してから所定時間が経過した後であってもラッチフラグがOFFである場合には、同期用データを受信しても送信処理を開始しないこととすればよい。
【0120】
また、モータECU2は、同期禁止期間内に同期用データを受信した場合には、同期用IDに基づく送信処理の開始等の所定処理は行わないが、同期用IDとともに送られてきたデータ情報については破棄することなく演算処理に使用するようにしてもよい。
【0121】
次に、モータECU2の具体的動作について図8を用いて説明する。図8は、モータECU2が実行する処理手順の一例を示すフローチャート(その1)である。なお、図8には、ハードウェア部からの受信割り込みがあった場合に実行される処理手順を示している。より具体的には、図8には、図7に示した動作、すなわち、受信済フラグおよびラッチフラグを用いて同期禁止期間を決定する場合の動作の処理手順について示している。
【0122】
図8に示すように、モータECU2の制御部225は、受信データが同期用データであるか否かを判定する(ステップS101)。具体的には、制御部225は、受信したフレームデータに含まれるIDが同期用IDであれば、受信データが同期用データであると判定する。
【0123】
同期用データである判定すると(ステップS101,Yes)、制御部225は、受信済フラグがONかつラッチフラグがONであるか否かを判定し(ステップS102)、受信済フラグがONかつラッチフラグがONであれば(ステップS102,Yes)、送信処理を開始する(ステップS103)。また、制御部225は、受信済フラグをOFFするとともに(ステップS104)、ラッチフラグをOFFする(ステップS105)。
【0124】
なお、同期用データであると判定された場合には、IDに基づいてデータの種別が判別され、この同期用IDとともに送られてきたデータ情報(データ領域に記憶された情報)は、判別された種別のデータ(たとえば、トルク指令値のデータ)であるとして、後の演算処理に用いられる。
【0125】
また、ステップS102において受信済フラグがONかつラッチフラグがONという条件を満たしていないとき(ステップS102,No)、制御部225は、受信データを破棄する(ステップS106)。この結果、送信処理は開始されない。
【0126】
一方、ステップS101において受信データが同期用データでない場合(ステップS101,No)、制御部225は、受信データが最終データであるか否かを判定する(ステップS107)。そして、受信データが最終データであると判定すると(ステップS107,Yes)、制御部225は、受信済フラグをONする(ステップS108)。
【0127】
ステップS105,S106,S108の処理を終えたとき、あるいは、ステップS107において受信データが最終データでない場合(ステップS107,No)、制御部225は、処理を終了する。なお、このフローチャート(その1)における処理は、受信割り込みがある毎に繰り返し処理される。
【0128】
つづいて、モータECU2の通信周期の開始時においてモータECU2が実行する処理手順について図9を用いて説明する。図9は、モータECU2が実行する処理手順の一例を示すフローチャート(その2)である。図9に示すように、モータECU2の制御部225は、あらたな通信周期が到来すると、ラッチフラグをONする(ステップS201)。
【0129】
上述してきたように、本実施例では、HV−ECU1のデータ格納処理部が、データの種別を表すID情報とデータの内容を表すデータ情報とを含んだフレームデータをモータECUへ送信し、モータECUの演算処理部が、HV−ECUからフレームデータを受信すると、受信したフレームデータに記憶されたデータ情報を、受信したフレームデータに記憶されたID情報のデータ種別のデータであると判断して、当該データ情報を用いて所定の演算処理を行う。
【0130】
また、モータECUのデータ格納処理部が、HV−ECUから受信したフレームデータのID情報が同期用IDであった場合には、上記したデータ情報を用いた所定の演算処理を行うとともに、通信周期内に送信すべきフレームデータのHV−ECUへの送信処理を開始することとした。したがって、データ通信の効率を高めることができる。
【0131】
以上、本発明に係る通信システムの実施例を図面に基づいて詳細に説明したが、これらは例示であり、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【0132】
たとえば、上述してきた実施例では、HV−ECUが、予め演算していた(すなわち、前回の通信周期で演算していた)1周期(今回の通信周期)に送信する必要があるフレームデータを、所定周期(通信処理周期)ごとに分割して送信バッファにセットする場合の例について説明した。
【0133】
しかし、これに限ったものではなく、HV−ECUは、通信周期が開始されてから所定の演算を開始し、所定周期(通信処理周期)が経過するごとに、それまでに演算が終わったデータで、まだ送信を行っていないフレームデータを送信バッファにセットするようにしてもよい。また、かかる場合においてHV−ECUは、毎回決まった数のフレームデータを送信バッファにセットするようにしてもよいし、演算の処理経過状況に応じて、通信処理周期ごとにセットするフレームデータ数が変わるようにしてもよい。
【0134】
また、上述してきた実施例では、ID読取部225aが読み取ったIDが同期用IDである場合に、データ格納処理部225bが、HV−ECU1への送信データをプラットフォーム224経由で送信バッファ222へ格納する送信処理を開始することとしたが、これに限ったものではない。たとえば、モータECU2のハードウェア部に同期用IDを識別する機能を持たせて自動的に送信処理を開始するようにしてもよい。
【0135】
また、上述してきた実施例では、通信装置間で、1つの通信周期において最初に送信するフレームデータとして、決まったIDのフレームデータを送付するように取り決めておくことで、通信周期の開始を知らせることとした。
【0136】
しかし、本発明に係る通信システムは、これに限ったものではなく、通信装置間で、1つの通信周期において最後に送信するフレームデータとして、決まったIDのフレームデータを送付するように取り決めておくことで、送信完了(あるいは受信完了)を知らせる場合にも適用可能である。
【産業上の利用可能性】
【0137】
以上のように、本発明に係る通信システムおよび通信装置は、データ通信の効率を高めたい場合に有効であり、特に、車載ECU間を相互に接続する車載ネットワークへの適用が考えられる。
【符号の説明】
【0138】
1 HV−ECU(第1の通信装置)
11 CANトランシーバ
12 マイコン
121 通信部
122 送信バッファ
123 受信バッファ
124 プラットフォーム
125 制御部
125a データ格納処理部
125b 受信完了処理部
2 モータECU(第2の通信装置)
21 CANトランシーバ
22 マイコン
221 通信部
222 送信バッファ
223 受信バッファ
224 プラットフォーム
225 制御部
225a ID読取部
225b データ格納処理部
225c 演算処理部
3 モータ
図1
図2
図3
図4
図5
図6
図7
図8
図9