JP5409681B2 - 通信システム - Google Patents

通信システム Download PDF

Info

Publication number
JP5409681B2
JP5409681B2 JP2011065646A JP2011065646A JP5409681B2 JP 5409681 B2 JP5409681 B2 JP 5409681B2 JP 2011065646 A JP2011065646 A JP 2011065646A JP 2011065646 A JP2011065646 A JP 2011065646A JP 5409681 B2 JP5409681 B2 JP 5409681B2
Authority
JP
Japan
Prior art keywords
data
communication
ecu
cycle
bus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011065646A
Other languages
English (en)
Other versions
JP2012204932A (ja
Inventor
貴志 松井
伸一郎 ▲高▼冨
誠志 福井
一司 真鼻
宗徳 中村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Ten Ltd
Toyota Motor Corp
Original Assignee
Denso Ten Ltd
Toyota Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Denso Ten Ltd, Toyota Motor Corp filed Critical Denso Ten Ltd
Priority to JP2011065646A priority Critical patent/JP5409681B2/ja
Publication of JP2012204932A publication Critical patent/JP2012204932A/ja
Application granted granted Critical
Publication of JP5409681B2 publication Critical patent/JP5409681B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Description

この発明は、通信装置間で通信を行う通信システムに関する。
従来、エンジンECU(Electronic Control Unit)やモータECUなどの電子制御ユニット間の通信方式として、CAN(Controller Area Network)通信が知られている。CAN通信は、電子制御ユニット間で送受信される各種の命令や制御の伝送をCANバスと呼ばれる通信線を用いて行うものであり、安価で自由度の高い通信方式として広く利用されている(たとえば、特許文献1参照)。
また、CAN通信では、マスタやスレーブといった主従関係を決めず、それぞれの電子制御ユニットが任意の通信タイミングでデータの送信を行う所謂マルチマスタ方式が採用されている。
なお、マルチマスタ方式を採用した場合、複数の電子制御ユニットからCANバスに対してデータが同時に送信されることがあるが、1つのCANバス上で複数のデータが同時に存在することはできない。このため、CAN通信では、データごとに優先順位を設け、優先順位の高いデータから順に伝送を行う通信調停を行うことによって通信の衝突を回避している。
しかしながら、CAN通信には、安価で自由度が高い反面、データ通信の効率があまり高くないといった課題がある。たとえば、CAN通信では、電子制御ユニット間でデータのやり取りを行う場合に、CANバスに無駄な空き時間が生じることがあった。
すなわち、CAN通信では、上記のように電子制御ユニット間の通信タイミングが同期されていないため、一方の電子制御ユニットからの送信データがCANバスに出力されてから他方の電子制御ユニットからの送信データがCANバスに出力されるまでに無駄な空き時間が生じるおそれがあった。
また、電子制御ユニットは、通信タイミングが到来すると、相手に送信すべきデータを送信バッファへ格納する処理を開始し、かかる処理が完了したのち、送信バッファに格納されたデータをCANバスへ出力することとしている。このとき、送信バッファへのデータの格納が完了するまでには、ある程度の時間がかかる。すなわち、電子制御ユニットは、通信タイミングが到来したとしても、すぐにはデータを送信することができないため、これによってもCANバスに無駄な空き時間が生じるおそれがあった。
このようにCANバスに無駄な空き時間が生じると、特に、所定の制御周期(たとえば、8ms)においてデータの送受信を複数回繰り返して1つの処理を完了させたい場合に、かかる制御周期内に全てのデータを送信しきれないおそれがある。このことから、車両内の通信で多量のデータを短時間で送受信する必要がある場合には、高速UART(Universal Asynchronous Receiver Transmitter)通信などの高速通信方式が用いられている。
特開2003−264567号公報
しかしながら、このような高速通信方式は、トランシーバや通信線等といった必要なハードウェア構成が多く、CAN通信と比べてコストがかかるという問題がある。
開示の技術は、上述した従来技術による問題点を解消するためになされたものであり、安価な構成でデータ通信の効率を高めることができる通信システムを提供することを目的とする。
本願は、第1の通信装置および第2の通信装置間の通信を所定の通信線を介して行う通信システムであって、前記第1の通信装置は、前記第2の通信装置に送るデータを第1の送信バッファへ格納する第1の制御部と、前記第1の制御部によって前記第1の送信バッファへ格納されたデータを所定の通信プロトコルに従って前記通信線へ出力する第1の通信部とを備え、前記第2の通信装置は、前記通信線から入力されたデータの受信バッファへの格納および第2の送信バッファへ格納されたデータの前記通信線への出力を前記所定の通信プロトコルに従って行う第2の通信部と、前記受信バッファへ格納されたデータが所定の通信周期の開始を示すデータであった場合に、前記所定の通信周期内に前記第1の通信装置に送る必要がある全てのデータを前記第2の送信バッファへ一括して格納する第2の制御部とを備えることを特徴とする。
本願によれば、安価な構成でデータ通信の効率を高めることができるという効果を奏する。
図1は、本願に係る通信手法の概要を示す図である。 図2は、本実施例に係る通信システムの構成例を示す図である。 図3は、HV−ECUおよびモータECUの構成を示すブロック図である。 図4は、フレームデータのフレーム構成の一例を示す図である。 図5は、通信周期内に送信すべきデータと開始IDとの対応関係の一例を示す図である。 図6は、HV−ECUおよびモータECUの動作例を示す図である。 図7は、CANプロトコルに基づくデータ出力処理の一例を示す図である。 図8は、所定の通信周期におけるHV−ECUおよびモータECUの通信タイミングの一例を示すタイミングチャートである。 図9は、HV−ECUが実行する送信処理の処理手順を示すフローチャートである。 図10は、モータECUが実行する送信処理の処理手順を示すフローチャートである。 図11は、HV−ECUおよびモータECUが実行する受信処理の処理手順を示すフローチャートである。
以下に添付図面を参照して、本発明に係る通信システムの実施例を詳細に説明する。まず、実施例の詳細な説明に先立ち、本願に係る通信手法の概要について図1を用いて説明する。図1は、本願に係る通信手法の概要を示す図である。図1の(A)には、従来のCAN通信の概要を、図1の(B)には、本願に係る通信手法の概要を、それぞれ示している。
図1の(A)および(B)では、2周期分の通信処理周期を1つの制御周期として、第1の通信装置および第2の通信装置が、それぞれ8フレームのデータを送信し合う場合の例を示している。ここで、「制御周期」とは、第1の通信装置で行われる所定の制御処理の処理周期のことであり、またここでは、所定の制御処理のために必要な、第1の通信装置および第2の通信装置間で行われる通信処理を完了させる必要がある期間のことでもある。「通信処理周期」とは、通信周期内に通信のために行う処理の処理周期である。なお、以下では、制御周期が通信周期と同じである場合の例について説明するが、制御周期は、通信周期と周期の長さや開始タイミングが異なってもよい。
図1の(A)に示すように、従来のCAN通信では、第1の通信装置および第2の通信装置間で通信を行う場合に、CANバスに無駄な空き時間が生じるおそれがあった。
具体的には、CAN通信では、第1の通信装置および第2の通信装置間で通信タイミングが同期されていない。このため、通信タイミングのずれ方によっては、一方の通信装置からの送信データがCANバスに出力されてから他方の通信装置からの送信データがCANバスに出力されるまでに無駄な空き時間が生じるおそれがあった。
たとえば、図1の(A)に示した例では、第1の通信装置からのフレームデータ4がCANバスへ出力されてから第2の通信装置からのフレームデータ1がCANバスへ出力されるまでの間にこのような空き時間が発生している。また、第1の通信装置からのフレームデータ8がCANバスへ出力されてから第2の通信装置からのフレームデータ5がCANバスへ出力されるまでの間においても同様である。
また、第1の通信装置および第2の通信装置のそれぞれは、通信処理周期が到来すると、相手に送信すべきデータを送信バッファへ格納する処理を開始し、かかる処理が完了したのち、送信バッファに格納されたデータをCANバスへ出力する。このとき、送信バッファへのデータ格納が完了するまでには、ある程度の時間がかかる。すなわち、電子制御ユニットは、通信タイミングが到来しても、すぐにはデータを送信することができないため、これによってもCANバスに空き時間が生じるおそれがあった。
たとえば、図1の(A)では、第2の通信装置からのフレームデータ4がCANバスへ出力されてから第1の通信装置からのフレームデータ5がCANバスへ出力されるまでの間にこのような空き時間が発生している。
このように、CANバスに無駄な空き時間が生じると、通信周期内に完了させるべき処理がかかる通信周期内で完了しない場合がある。具体的には、図1の(A)に示したように、通信周期内に送信すべきデータ(ここでは、8つのフレームデータ)を通信周期内に送信しきれないおそれがある。
そこで、本願に係る通信手法では、通信周期内で完了させるべき処理の開始タイミングを第1の通信装置および第2の通信装置間で同期させることとし、かつ、第2の通信装置が、通信周期内で送信すべきデータの全てを送信バッファへ一括して格納することとした。そして、本願に係る通信手法では、送信バッファへ格納されたデータをCANプロトコルに従ってCANバスへ順次出力していくことで、CANバスに上記のような無駄な空き時間が発生することを防止することとした。
具体的には、図1(B)に示すように、マスタノードである第1の通信装置は、通信周期(すなわち、第1の通信装置の制御周期)の開始時に、かかる通信周期の開始を示す開始IDを含んだデータを送信バッファへ格納する。かかる開始IDは、専用のIDであってもよいし、従来のCAN通信で用いられるIDを流用してもよい。なお、従来のCAN通信で用いられるIDは、データの種別と、後述する通信調停を行う際にデータの優先順位を示すものである。
第1の通信装置は、データを送信バッファへ格納すると、送信バッファへ格納したデータをCANプロトコルに従ってCANバスへ出力する(図1の(B)の(1)参照)。
具体的には、第1の通信装置は、CANバスに対してデータを出力する際に、CANバスの使用状況を確認し、CANバスが使用されていなければ、CANバスへのデータ出力を実行する。また、第1の通信装置は、CANバスの競合が発生した場合には、相手側(ここでは、第2の通信装置)が送信しようとしているデータの優先順位と自装置が送信しようとしているデータの優先順位とを比較する。そして、自装置が送信しようとしているデータの優先順位が高ければ、相手側よりも先にCANバスへのデータ出力を行う。一方、相手側のデータの優先度が高ければ、相手側のデータ出力を優先させ、CANが空き状態となったのちにCANバスへのデータ出力を行う。なお、このような処理は「通信調停」と呼ばれる。
ここでは、マスタノードである第1の通信装置から送信されるデータの優先順位が、スレーブノードである第2の通信装置から送信されるデータの優先順位よりも高く設定される。このため、第1の通信装置は、第2の通信装置との間でCANバスの競合が発生した場合でも、第2の通信装置よりも優先的にCANバスへのデータ出力を行うこととなる。
第2の通信装置は、第1の通信装置からCANバスを介してデータを受信すると、受信したデータを受信バッファへ格納する。また、第2の通信装置は、受信バッファへ格納されたデータに開始IDが含まれる場合に、かかる開始IDに対応するデータであって、所定の通信周期内に送信すべき全てのデータ(ここでは、8フレームのデータ全て)を送信バッファへ一括して格納する(図1の(B)の(2)参照)。
そして、第2の通信装置は、送信バッファへ格納されたデータをCANプロトコルに従ってCANバスへ順次出力する。すなわち、第2の通信装置も、第1の通信装置と同様に、通信調停を適宜行いながらCANバスへのデータ出力を行う。
ここで、第2の通信装置から送信されるデータの優先順位は、上記のように第1の通信装置から送信されるデータの優先順位よりも低く設定されている。このため、第2の通信装置は、CANバスへのデータ出力中に、第1の通信装置からCANバスへのデータ出力がなされると、自装置からのデータ出力を中断し、CANバスが空き状態となるのを待ってからデータ出力を再開することとなる(図1の(B)の(3)参照)。
なお、ここでは、第2の通信装置から送信される全てのデータの優先順位が、第1の通信装置から送信されるデータの優先順位よりも低く設定されるものとするが、これに限ったものではない。すなわち、第2の通信装置から送信されるデータのうち一部のデータの優先順位が、第1の通信装置から送信されるデータの優先順位よりも高く設定されることとしてもよい。ただし、かかる場合であっても、開始IDについては、第2の通信装置から送信される何れのデータよりも優先順位を高く設定しておくものとする。
この結果、CANバスには、第1の通信装置からのデータおよび第2の通信装置からのデータがすき間なく出力されることとなり、CANバスに無駄な空き時間が生じることが防止される。
このように、本願に係る通信手法では、マスタノードである第1の通信装置が、開始IDを含んだデータをスレーブノードである第2の通信装置へ送信することによって、第1の通信装置および第2の通信装置間で通信タイミングを同期させる。また、本願に係る通信手法では、第2の通信装置が、受信バッファへ格納されたデータに開始IDが含まれる場合に、かかる開始IDに対応するデータであって、通信周期内に送信すべき全てのデータを送信バッファへ格納し、送信バッファへ格納されたデータをCANプロトコルに従ってCANバスへ出力することとした。
このため、CANバスに無駄な空き時間が生じることがなく、データを効率的に伝送することが可能となる。さらに、本願に係る通信手法は、従来のCAN通信のハードウェア構成と同一の構成を用いて実現することができる。したがって、本願に係る通信手法によれば、安価な構成でデータ通信の効率を高めることができる。
以下では、本願に係る通信手法を適用した通信システムについての実施例を詳細に説明する。なお、以下の実施例では、通信システムの一例として、車載ECU間の通信システムを用いて説明する。また、以下では、パワートレイン系ECUを制御するHV−ECU(Hybrid Vehicle−ECU)を第1の通信装置の一例とし、パワートレイン系ECUの一つであるモータECUを第2の通信装置の一例として説明する。
まず、本実施例に係る通信システムの構成例について図2を用いて説明する。図2は、本実施例に係る通信システムの構成例を示す図である。
図2に示すように、本実施例に係る通信システムでは、HV−ECU1とモータECU2とが、CANバスを介して相互に接続される。CANバスは、CAN_HiラインおよびCAN_Loラインからなる2線式の通信線である。また、モータECU2は、モータ3と接続する。
HV−ECU1は、マスタノードであり、モータECU2等の車両に設けられた各種ECUと連携してモータ3やエンジン等の全体的な制御を行う。また、モータECU2は、スレーブノードであり、HV−ECU1からの命令に従ってモータ3の具体的な制御を行う。
たとえば、HV−ECU1は、CANバスを介してモータのトルク指令値をモータECU2へ送信する。また、モータECU2は、CANバスを介してHV−ECU1からトルク指令値を受信すると、受信したトルク指令値に基づいてモータ3の制御を行う。また、モータECU2は、モータ3に対する制御の結果をHV−ECU1へ送信する。かかる一連の処理はあらかじめ決められた所定の通信周期内で行われる。
また、HV−ECU1は、CANトランシーバ11とマイコン12とを備える。同様に、モータECU2も、CANトランシーバ21とマイコン22とを備える。ここで、CANトランシーバ11,21、マイコン12,22内のハードウェア部、CANバスといったハードウェアは、CAN通信用のハードウェアをそのまま流用したものである。このように、本実施例に係る通信システムは、CAN通信と同様、安価な構成を用いて実現することが可能である。
なお、図2に示すように、HV−ECU1は、モータECU2と接続するためのCANバスとは別に、たとえばエンジンECU4や電池ECU5といった車両に設けられた様々なECUと接続するためのバス(たとえば、CANバス)とも接続する。
また、図2に示すように、HV−ECU1とモータECU2とを接続するCANバスには、HV−ECU1およびモータECU2のみが接続されるものとするが、CANバスには3つ以上の通信装置(ECU)を接続することも可能である。
次に、HV−ECU1およびモータECU2の構成について図3を用いて説明する。なお、図3では、HV−ECU1およびモータECU2の特徴を説明するために必要な構成要素のみを示しており、一般的な構成要素についての記載を省略している。
図3に示すように、HV−ECU1は、CANトランシーバ11およびマイコン12を備える。マイコン12は、通信部121と、送信バッファ122と、受信バッファ123と、プラットフォーム124と、制御部125とを備える。制御部125は、データ格納処理部125aと、受信完了処理部125bとを備える。
また、モータECU2は、CANトランシーバ21と、マイコン22とを備える。また、マイコン22は、通信部221と、送信バッファ222と、受信バッファ223と、プラットフォーム224と、制御部225とを備える。また、制御部225は、ID読取部225aと、データ格納処理部225bとを備える。
まず、HV−ECU1の構成について説明する。CANトランシーバ11は、マイコン12およびCANバス間のインタフェース用IC(Integrated Circuit)である。具体的には、CANトランシーバ11は、マイコン12で生成されたデータをCANバスへ出力するとともに、CANバスから入力されたデータをマイコン12へ出力する。
マイコン12は、モータECU2との間の通信をCANプロトコルに従って制御するマイクロコンピュータである。ここで、かかるマイコン12のうち、通信部121、送信バッファ122および受信バッファ123は、ハードウェアで構成され、プラットフォーム124および制御部125は、ソフトウェアで構成される。
通信部121は、データの送受信をCANプロトコルに従って実行するハードウェア部である。具体的には、通信部121は、送信バッファ122にデータが格納された場合には、かかる送信バッファ122に格納されたデータをCANプロトコルに従ってCANトランシーバ11経由でCANバスへ出力する。また、通信部121は、CANトランシーバ11からデータを受け取った場合には、受け取ったデータを受信バッファ123へ格納する。なお、CANプロトコルに基づき実行されるデータ送信処理(通信調停)の具体例については、図7を用いて後述することとする。
送信バッファ122は、他のECU(ここでは、モータECU2)に対して送信すべきデータを一時的に記憶するハードウェア部である。また、受信バッファ123は、他のECU(ここでは、モータECU2)から受信したデータを一時的に記憶するハードウェア部である。
なお、CANトランシーバ11、通信部121、送信バッファ122および受信バッファ123は、従来のCAN通信で用いられるCANトランシーバ、通信部、送信バッファおよび受信バッファを流用することができるが、これに限ったものではない。すなわち、本実施例に係る通信システム専用のトランシーバ、通信部、送信バッファおよび受信バッファを用いてもよい。
プラットフォーム124は、ソフトウェア部である制御部125によって生成されたデータをハードウェア部である送信バッファ122へ渡す処理を行う処理部である。また、プラットフォーム124は、ハードウェア部である受信バッファ123から受け取ったデータをソフトウェア部である制御部125へ渡す処理を行う処理部でもある。
制御部125は、たとえばCPU(Central Processing Unit)であり、モータECU2との通信に関する処理等を実行するソフトウェア部である。かかる制御部125は、特に、データ格納処理部125aと、受信完了処理部125bとを備える。
データ格納処理部125aは、モータECU2への送信データをプラットフォーム124経由で送信バッファ122へ格納する処理部である。具体的には、データ格納処理部125aは、モータECU2へ送信すべきデータを所定のブロック(たとえば、4フレームごと)に分割し、かかる分割データを通信処理周期ごとに送信バッファ122へ格納する。
特に、データ格納処理部125aは、通信周期の開始時に、かかる通信周期の開始を示す開始IDを含んだデータを送信バッファ122へ格納する。ここで、本実施例に係る通信システムにおいて送受信されるフレームデータのフレーム構成について図4を用いて説明する。図4は、フレームデータのフレーム構成の一例を示す図である。
図4に示すように、フレームデータには、データの内容を表す0〜8Byteのデータ情報が含まれる。また、フレームデータには、IDが含まれる。IDは、たとえば11Bitであらわされる値であり、従来のCAN通信においては、データの種別を示す情報であるとともに、通信調停におけるデータの優先順位を示す情報である。
フレームデータに含まれるIDには、通常のデータであり、「トルク指令値」や「モータ回転数」といったこのデータの種別と、このデータの優先順位を示す「通常ID」と、データの優先順位に加え、通信周期の開始を示す「開始ID」や検査モードにモード移行することを指示する「検査ID」といった制御情報を含む「制御ID」の2種類のIDが存在する。すなわち、本実施例に係る通信システムでは、従来のCAN通信で用いられるIDに「制御ID」を設け、この「制御ID」のひとつとして「開始ID」を設けることとしている。このように、「開始ID」は、データの優先順位を示す情報であり、かつ、通信周期の開始を示す情報でもある。
なお、制御情報に付与する制御IDを、通常データに付与する通常IDとは別個に設けることとしてもよい。かかる場合の制御IDは、従来のCAN通信で用いられるIDと同じビット数(ここでは、11Bit)である必要はなく、より少ないビット数で表現することとしてもよい。
また、ここでは、通信周期の開始を示す情報をIDに持たせることとしたが、これに限ったものではなく、たとえば、通信周期の開始を示す命令情報をデータとして格納することとしてもよい。かかる場合、IDは、通常IDにおける何らかのデータをあらわすIDで、データ内容だけを命令情報に置き換えるようにしてもよいし、未使用のIDを命令情報送信用のIDとして用いてもよい。
図3へ戻り、HV−ECU1の制御部125についての説明を続ける。受信完了処理部125bは、モータECU2から通信周期内における最終データを受信した場合に、受信完了処理を行う処理部である。たとえば、受信完了処理部125bは、モータECU2から最終データを受信すると、サムチェックを実施し、モータECU2から全てのフレームデータを正常に受信できたか否かを判定する。
なお、図3では、制御部125が備える処理部として、データ格納処理部125aおよび受信完了処理部125bのみを示したが、制御部125は、モータECU2から受信したデータを用いて所定の演算を行う演算処理部などの他の処理部を備えていてもよい。
次に、モータECU2の構成について説明する。なお、モータECU2のハードウェア、具体的には、CANトランシーバ21、通信部221、送信バッファ222および受信バッファ223は、HV−ECU1のハードウェアと同一構成であるため、ここでの説明は省略する。また、プラットフォーム224についても、HV−ECU1のプラットフォーム124と同様の処理部であるため、ここでの説明は省略する。
モータECU2の制御部225は、たとえばCPUであり、HV−ECU1との通信に関する処理等を実行するソフトウェア部である。かかる制御部225は、ID読取部225aと、データ格納処理部225bなどを備える。
ID読取部225aは、受信バッファ223へ格納されたデータのIDを読み取り、読み取ったIDが開始IDである場合に、かかる開始IDをデータ格納処理部225bへ渡す処理を行う処理部である。なお、どのIDが開始IDであるかは、あらかじめ決められているものとする。
データ格納処理部225bは、HV−ECU1への送信データをプラットフォーム224経由で送信バッファ222へ格納する処理部である。データ格納処理部225bは、ID読取部225aから開始IDを受け取ると、受け取った開始IDに対応するデータ、すなわち、通信周期内に送信すべきデータを、所定ブロックごとではなく一括して送信バッファ222へ格納する処理を行う。
ここで、通信周期内に送信すべきデータと開始IDとの対応関係について図5を用いて説明する。図5は、通信周期内に送信すべきデータと開始IDとの対応関係の一例を示す図である。
図5に示すように、開始IDには、通信周期内に送信すべきデータがあらかじめ対応付けられている。図5に示した例では、開始ID「1111***」には「データA」が、開始ID「1122***」には「データB」がそれぞれ対応付けられている。なお、「データA」や「データB」は、データの値そのものではなく、データの種別をあらわすものである。
たとえば、データ格納処理部225bは、トルク閾値を変更する処理の開始を示す開始ID「1111***」を受け取ると、モータ3のトルク値などを「データA」として取得し、一括して送信バッファ222へ格納する。
なお、図3では、制御部225が備える処理部として、ID読取部225aおよびデータ格納処理部225bのみを示したが、制御部225は、他の制御部を備えていてもよい。たとえば、制御部225は、HV−ECU1から最終データを受信した場合に、受信完了処理を実行する受信完了処理部や、HV−ECU1から受信した制御命令に従ってモータ3を制御するモータ制御部などを備えていてもよい。
次に、HV−ECU1およびモータECU2の動作例について説明する。図6は、HV−ECU1およびモータECU2の動作例を示す図である。なお、図6の(A)には、HV−ECU1のデータ送信処理時の動作例を、図6の(B)には、モータECU2がHV−ECU1からのデータを受信し、対応するデータを送信バッファ222へ格納するまでの動作例を、それぞれ示している。
図6の(A)に示すように、HV−ECU1は、あらたな通信周期が到来すると、モータECU2へのデータ送信を開始する。具体的には、HV−ECU1では、データ格納処理部125aが、通信周期内に送信すべきデータを4フレームごとに分割した分割データを自装置の通信処理周期ごとに送信バッファ122へ格納する。また、HV−ECU1では、通信部121が、送信バッファ122に分割データが格納されるごとに、かかる分割データを、CANトランシーバ11を介してCANバスへ出力する。
ここで、HV−ECU1からモータECU2に対して最初に送信される分割データの先頭のデータには、かかる通信周期の開始を示す開始IDが含まれている。ここでは、通信周期内に送信すべきデータを4フレームごとに分割することとしたが、データの分割単位は4フレームである必要はない。
なお、HV−ECU1は、今回の通信周期が開始されると、前回の通信周期においてモータECU2から送られてきていた、モータ回転数といったモータの状態に関する情報等や、別のバスから送られてくる運転者のアクセルの踏み込み状態(運転者が求めているトルク量)、電池の充電状態等の車両制御に関する各種情報に基づいて、モータやエンジンで出力する必要があるトルク量(トルク指令値)等を算出する演算処理を行う。
一方、モータECU2では、図6の(B)に示すように、ハードウェア部から受信割り込みを受けると、ID読取部225aが、HV−ECU1から受信した分割データに含まれるIDを読み取る。ID読取部225aは、読み取ったIDの中に開始IDが含まれる場合には、開始IDをデータ格納処理部225bへ渡す。なお、ここでは、開始IDが「1111***」であったとする。
データ格納処理部225bは、ID読取部225aから開始IDを受け取ると、受け取った開始IDに対応するデータを取得し、取得したデータを一括して送信バッファ222へ格納する。ここでは、開始ID「1111***」を受け取ったため、データ格納処理部225bは、かかる開始ID「1111***」に対応するデータAをモータ3などから取得し(図5参照)、取得したデータAを送信バッファ222へ格納する。
なお、モータECU2は、HV−ECU1から開始IDを受信すると、取得した現在のモータ回転数といったモータの状態(前回の通信周期で、HV−ECU1から送られてきたトルク指令値等に基づいてモータを制御した後のモータの状態)に関する情報や、前回の通信周期におけるモータECU2での演算結果のうち、HV−ECU1に送信する必要があるデータ等を、一括して送信バッファ222にセットする。
次に、モータECU2の通信部221が、送信バッファ222に格納されたデータをCANプロトコルに従ってCANバスへ出力する処理の動作例について図7を用いて説明する。図7は、CANプロトコルに基づくデータ出力処理の一例を示す図である。なお、ここでは、送信バッファ222に格納されたデータAがn個のフレームデータで構成される場合の例を示している。
図7に示すように、モータECU2の通信部221は、HV−ECU1との間で通信調停を適宜行いながら、CANバスへのデータ出力を行う。具体的には、通信部221は、CANバスが空き状態であるか否かを確認し、空き状態であれば、送信バッファ222に格納されたデータAを1フレームずつCANバスへ出力していく。図7に示した場合には、フレームデータ1〜4がCANバスへ出力されている。
つづいて、モータECU2の通信部221がフレームデータ5をCANバスへ出力しようとした際に、HV−ECU1との間でCANバスの競合が発生したとする。かかる場合、通信部221は、HV−ECU1のデータ出力を優先させ、CANが空き状態となったのちに、フレームデータ5をCANバスへ出力する。これは、モータECU2からのデータの優先度が、HV−ECU1からのデータの優先度よりも低く設定されているためである。
このように、モータECU2の通信部221は、送信バッファ222に格納された各フレームデータを絶えずCANバスへ出力しようとするが、HV−ECU1との間でCANバスの競合が発生した場合には、HV−ECU1からのデータ出力を優先させる。この結果、CANバスには、モータECU2からのデータとHV−ECU1からのデータとが隙間なく出力されることとなる。すなわち、CANバスへのデータの送出は、モータECU2からのデータよりもHV−ECU1からのデータが優先されることとしたため、HV−ECU1およびモータECU2間の通信を、CANバスに無駄な空き時間を生じさせることなく行うことができる。
次に、所定の通信周期におけるHV−ECU1およびモータECU2の通信タイミングについて図8を用いて説明しておく。図8は、所定の通信周期におけるHV−ECU1およびモータECU2の通信タイミングの一例を示すタイミングチャートである。
ここで、図8では、HV−ECU1およびモータECU2の通信処理周期がそれぞれ1msであり、通信周期(HV−ECU1の制御周期)が8周期分の通信処理周期に相当する8msであるものとする。また、図8では、HV−ECU1とモータECU2との間で、制御周期の開始・終了タイミングの同期を取ることなく、通信処理周期および制御周期の長さのみを同じ長さに設定する場合の例を示している。
図8に示すように、HV−ECU1の制御部125は、通信周期が到来すると、前回の通信周期において取得したデータをラッチ(保持)する処理や今回の通信周期において送信したいデータのSUM値を算出する処理を行う(図8の(1a)参照)。ここで、SUM値とは、各フレームデータのうちSUM値を除いた情報(IDやデータ等)を0および1の2進数であらわした情報とした場合に、その値を全て足し合わせた値である。算出されたSUM値は、各フレームデータに付加されることとなる。
また、HV−ECU1の制御部125は、かかる処理を終えたのち、モータECU2へ送信するデータの分割データのうち、最初の分割データを送信バッファ122へ格納する(図8の(1b)参照)。なお、かかる分割データの先頭のデータには、開始IDが含まれている。
HV−ECU1の送信バッファ122に分割データが格納されると、HV−ECU1の通信部121は、送信バッファ122に格納された分割データをCANバスへ出力する(図8の(1c)参照)。CANバスへ出力された分割データは、モータECU2の通信部221へ入力され、かかる通信部221によって受信バッファ223へ格納される。
モータECU2の制御部225は、受信バッファ223に分割データが格納されると、受信割り込みを発生させ、受信バッファ223に格納された分割データのIDを読み取る(図8の(2a)参照)。このとき、モータECU2の制御部225は、読み取ったIDに開始IDが含まれていれば、開始IDに対応する全てのデータを一括して送信バッファ222へ格納する(図8の(2b)参照)。
モータECU2の通信部221は、送信バッファ222にデータが格納されると、送信バッファ222に格納されたデータを1フレームずつCANバスへ出力していく。ただし、HV−ECU1との間でCANバスの競合が発生した場合には、HV−ECU1からのデータ出力が完了するのを待ってからデータ出力を再開させる。
なお、開始IDは、所定の通信周期においてHV−ECU1から最初に送信されるデータに埋め込まれている。このため、モータECU2は、通信周期内に送信すべきデータを送信バッファ222へ格納する処理を通信周期における早い段階で開始することができる。これにより、HV−ECU1からの最初の通信処理周期における最終フレームがCANバスへ出力されてから、モータECU2からの最初のデータがCANバスへ出力されるまでの間に、CANバスの空き時間が生じることを確実に防止することができる。
一方、HV−ECU1の制御部125は、通信周期内に受信すべきデータの最終フレームをモータECU2から受信すると、受信完了処理を実行する(図8の(1d)参照)。具体的には、HV−ECU1では、受信完了処理部125bが、通信周期内に受信したデータのSUM値を算出し、算出したSUM値をHV−ECU1から送信されたSUM値と比較することで、SUM値が正常であるか否かのサムチェックを行う。
なお、ここでは、1つの通信周期で受信した全てのフレームデータのSUMチェックをまとめて行う場合の例を示したが、これに限らず、フレームデータを受信するごとにSUMチェックを実行することとしてもよい。
また、モータECU2の制御部225も同様に、通信周期内に受信すべきデータの最終フレームをHV−ECU1から受信すると、受信完了処理を実行する(図8の(2c)参照)。
次に、HV−ECU1およびモータECU2の具体的動作について説明する。まず、HV−ECU1が実行する送信処理の処理手順について図9を用いて説明する。図9は、HV−ECU1が実行する送信処理の処理手順を示すフローチャートである。なお、図9においては、1つの通信周期における送信処理の処理手順を示している。
図9に示すように、HV−ECU1のデータ格納処理部125aは、あらたな通信周期が到来すると、モータECU2へ送信するデータの分割データのうち、最初の分割データを送信バッファ122へ格納する(ステップS101)。かかる分割データの先頭のフレームデータには、開始IDが含まれている。また、送信バッファ122に分割データが格納されると、HV−ECU1の通信部121は、送信バッファ122に格納された分割データをCANプロトコルに従ってCANバスへ出力する(ステップS102)。
つづいて、HV−ECU1のデータ格納処理部125aは、次の通信処理周期が到来したか否かを判定し(ステップS103)、次の通信処理周期が到来したと判定した場合には(ステップS103,Yes)、次の分割データを送信バッファ122へ格納する(ステップS104)。そして、分割データが送信バッファ122へ格納されると、通信部121が、かかる分割データをCANバスへ出力する(ステップS105)。
なお、本実施例では、マスタノードであるHV−ECU1からのデータが、スレーブノードであるモータECU2からのデータと比べて優先順位が高く設定されている。このため、通信部121は、送信バッファ122に分割データが格納されると、モータECU2との間でCANバスの競合が発生した場合であっても、モータECU2よりも優先的にデータ出力を行うこととなる。
つづいて、データ格納処理部125aは、全ての分割データの送信が完了したか否かを判定し(ステップS106)、完了していない場合には(ステップS106,No)、ステップS103へ戻り、全ての分割データの送信が完了するまでステップS103〜S106の処理を繰り返す。なお、ステップS103において次の通信処理周期が到来していない場合にも(ステップS103,No)、処理をステップS103へ戻す。そして、データ格納処理部125aは、全ての分割データの送信が完了すると(ステップS106,Yes)、処理を終了する。
次に、モータECU2が実行する送信処理の処理手順について図10を用いて説明する。図10は、モータECU2が実行する送信処理の処理手順を示すフローチャートである。なお、図10においては、モータECU2が、開始IDを含んだ分割データを受信してからかかる開始IDに対応するデータの送信を完了させるまでの処理手順を示している。
図10に示すように、モータECU2のID読取部225aは、HV−ECU1からデータを受信したか否かを判定する(ステップS201)。具体的には、ID読取部225aは、受信バッファ223にデータが格納されたか否かを判定する。
かかる処理において、データを受信した(すなわち、受信バッファ223にデータが格納された)と判定すると(ステップS201,Yes)、ID読取部225aは、受信バッファ223に格納されたデータから開始IDを読み取る(ステップS202)。なお、ステップS201においてデータを受信していない場合、すなわち、受信バッファ223にデータが格納されていない場合(ステップS201,No)、ID読取部225aは、ステップS201の判定処理を繰り返す。
つづいて、データ格納処理部225bは、ID読取部225aが読み取った開始IDに対応するデータを送信バッファ222へ全て格納する(ステップS203)。つづいて、モータECU2の通信部221は、送信バッファ222にデータが格納されると、まず、CANバスが使用可能か否かを判定する(ステップS204)。具体的には、通信部221は、CANバスが空き状態である場合(すなわち、HV−ECU1によって使用されていない場合)にCANバスが使用可能であると判定する。かかる処理において、CANバスが使用可能であると判定すると(ステップS204,Yes)、通信部221は、送信バッファ222に格納されたデータの1フレームをCANバスへ出力する(ステップS205)。
一方、通信部221は、HV−ECU1との間でCANバスの競合が発生した場合には、CANバスが使用不可であると判定する(ステップS204,No)。かかる場合、通信部221は、ステップS204の判定処理を繰り返す。すなわち、通信部221は、HV−ECU1のデータ出力を優先させ、CANバスが空き状態となったのちにCANバスへのデータ出力を行う。
つづいて、通信部221は、送信バッファ222に格納された全てのデータの送信が完了したか否かを判定し(ステップS206)、完了していない場合には(ステップS206,No)、ステップS204へ戻り、データの送信が全て完了するまでステップS204〜S206の処理を繰り返す。そして、全てのデータの送信が完了すると(ステップS206,Yes)、処理を終了する。
次に、HV−ECU1およびモータECU2が実行する受信処理の処理手順について図11を用いて説明する。図11は、HV−ECU1およびモータECU2が実行する受信処理の処理手順を示すフローチャートである。なお、図11においては、1つの通信周期における受信処理の処理手順を示している。また、ここでは一例として、HV−ECU1を主体として説明する。
図11に示すように、HV−ECU1の制御部125は、データを受信したか否か(すなわち、CANバスからデータが入力されたか否か)を判定する(ステップS301)。そして、通信部121は、データを受信したと判定すると(ステップS301,Yes)、受信データを受信バッファ123へ格納する(ステップS302)。なお、通信部121は、データを受信していない場合には(ステップS301,No)、ステップS301の判定処理を繰り返す。
つづいて、通信部121は、通信周期内に受信すべき全てのデータをモータECU2から受信したか否かを判定し(ステップS303)、未受信のデータがある場合には(ステップS303,No)、ステップS301へ戻り、ステップS301〜S303の処理を繰り返す。一方、全てのデータを受信したと判定した場合には(ステップS303,Yes)、処理をステップS304へ移行する。
ステップS304において、受信完了処理部125bは、今回の通信周期内に受信したデータのSUM値を算出し、かかるSUM値が正常であるか否かを判定する(ステップS304)。なお、かかる判定は、HV−ECU1から送信されたSUM値との比較により行われる。
かかる処理において、SUM値が正常であると判定すると(ステップS304,Yes)、制御部125は、今回の通信周期で受信したデータを次の通信周期が開始される直前に公開して(ステップS305)、処理を終了する。公開されたデータは、次の通信周期の開始時においてラッチされ、SUM値が算出される。一方、SUM値が正常ではない場合には(ステップS304,No)、所定の異常対応処理を行ったうえで(ステップS306)、処理を終了する。
なお、図11では、ステップS305に示したように、次の通信周期の開始直前に受信データを公開することとしたが、これに限ったものではなく、受信データの公開は、通信周期内における任意のタイミングで行うこととしてもよい。
上述してきたように、本実施例では、HV−ECUのデータ格納処理部が、モータECUへ送るデータを送信バッファへ格納し、HV−ECUの通信部が、送信バッファへ格納されたデータをCANプロトコルに従ってCANバスへ出力する。
また、本実施例では、モータECUの通信部が、CANバスから入力されたデータの受信バッファへの格納および送信バッファへ格納されたデータのCANバスへの出力をCANプロトコルに従って行い、モータECUのデータ格納処理部が、受信バッファへ格納されたデータが開始IDであった場合に、所定の通信周期内にHV−ECUへ送る必要がある全てのデータを送信バッファへ格納することとした。したがって、安価な構成でデータ通信の効率を高めることができる。言い換えれば、安価な構成を用いつつも、大量のデータ通信を短時間で送受信させることが可能となる。
以上、本発明に係る通信システムの実施例のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
たとえば、上述してきた実施例では、HV−ECU1が、予め演算していた(すなわち、前回の通信周期で演算していた)1周期(今回の通信周期)に送信する必要があるデータを、所定周期(通信処理周期)ごとに分割して送信バッファ122にセットする場合の例について説明した。
しかし、これに限ったものではなく、HV−ECU1は、通信周期が開始されてから所定の演算を開始し、所定周期(通信処理周期)が経過するごとに、それまでに演算が終わったデータで、まだ送信を行っていないデータを送信バッファ122にセットするようにしてもよい。また、かかる場合においてHV−ECU1は、毎回決まった数のフレームを送信バッファ122にセットするようにしてもよいし、演算の処理経過状況に応じて、通信処理周期ごとにセットするフレーム数が変わるようにしてもよい。
また、上述してきた実施例では、HV−ECU1が、通信周期内において送信すべきデータを分割して送信する場合の例について説明したが、HV−ECU1は、通信周期内において送信すべきデータを一括して送信することとしてもよい。
かかる場合、HV−ECU1からのデータのCANバスへの出力中に、モータECU2からのデータがモータECU2の送信バッファ222へ格納され、HV−ECU1からのデータ出力が完了した時点で、モータECU2からのデータ出力が開始されることとなる。したがって、HV−ECU1が通信周期内において送信すべきデータを一括して送信する場合であっても、CANバスに無駄な空き時間が生じることを防止することができる。
また、上述してきた実施例では、マスタノードであるHV−ECU1からのデータの優先度が、スレーブノードであるモータECU2からのデータの優先度よりも高く設定される場合の例について説明してきたが、これに限ったものではない。
たとえば、HV−ECU1が、通信周期内に送信すべきデータを一括して送信バッファ122へ格納し、モータECU2が、開始IDを含んだデータを受信してから所定時間計測したのちにデータの送信処理を開始する構成とする。かかる場合、モータECU2からのデータの優先度をHV−ECU1からのデータの優先度よりも高く設定したとしても、HV−ECU1からのデータ出力中に、モータECU2からのデータが優先的にCANバスへ出力されることとなるため、CANバスに無駄な空き時間を生じさせることなくデータ通信を行うことができる。
また、上述してきた実施例では、HV−ECU1およびモータECU2がCANプロトコルに従って通信を行うこととしたが、HV−ECU1およびモータECU2は、CANプロトコルと同様の通信調停を行う他の通信プロトコルに従って通信を行うこととしてもよい。また、ここでは、HV−ECU1およびモータECU2がCANバスを介して通信を行うこととしたが、CANバスに類するものであれば他の通信線を用いてもよい。
以上のように、本発明に係る通信システムは、安価な構成でデータ通信の効率を高めたい場合に有効であり、特に、車載ECU間を相互に接続する車載ネットワークへの適用が考えられる。
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 データ格納処理部
3 モータ

Claims (5)

  1. 第1の通信装置および第2の通信装置間の通信を所定の通信線を介して行う通信システムであって、
    前記第1の通信装置は、
    前記第2の通信装置に送るデータを第1の送信バッファへ格納する第1の制御部と、
    前記第1の制御部によって前記第1の送信バッファへ格納されたデータを所定の通信プロトコルに従って前記通信線へ出力する第1の通信部と
    を備え、
    前記第2の通信装置は、
    前記通信線から入力されたデータの受信バッファへの格納および第2の送信バッファへ格納されたデータの前記通信線への出力を前記所定の通信プロトコルに従って行う第2の通信部と、
    前記受信バッファへ格納されたデータが所定の通信周期の開始を示すデータであった場合に、前記所定の通信周期内に前記第1の通信装置に送る必要がある全てのデータを前記第2の送信バッファへ一括して格納する第2の制御部と
    を備えることを特徴とする通信システム。
  2. 前記通信線へのデータの送出は、前記第2の通信装置からのデータよりも前記第1の通信装置からのデータが優先されることを特徴とする請求項1に記載の通信システム。
  3. 前記第1の制御部は、
    前記通信周期よりも短い通信処理周期ごとに前記第2の通信装置に送るデータを前記第1の送信バッファへ格納することを特徴とする請求項1または2に記載の通信システム。
  4. 前記第1の制御部は、
    前記通信周期が始まった後の最初の通信処理周期において前記通信周期の開始を示すデータを含むデータを前記第1の送信バッファへ格納することを特徴とする請求項3に記載の通信システム。
  5. 前記第1の通信部および前記第2の通信部は、
    前記通信線へのデータ出力をCAN(Controller Area Network)プロトコルに従って実行する通信デバイスであることを特徴とする請求項1〜4のいずれか一つに記載の通信システム。
JP2011065646A 2011-03-24 2011-03-24 通信システム Expired - Fee Related JP5409681B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011065646A JP5409681B2 (ja) 2011-03-24 2011-03-24 通信システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011065646A JP5409681B2 (ja) 2011-03-24 2011-03-24 通信システム

Publications (2)

Publication Number Publication Date
JP2012204932A JP2012204932A (ja) 2012-10-22
JP5409681B2 true JP5409681B2 (ja) 2014-02-05

Family

ID=47185470

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011065646A Expired - Fee Related JP5409681B2 (ja) 2011-03-24 2011-03-24 通信システム

Country Status (1)

Country Link
JP (1) JP5409681B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10397041B2 (en) 2016-09-09 2019-08-27 Denso Corporation Electronic control unit

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3551905B2 (ja) * 2000-09-01 2004-08-11 オムロン株式会社 管理局及びネットワークシステム並びにネットワークシステムにおける通信方法
JP4032779B2 (ja) * 2002-03-11 2008-01-16 トヨタ自動車株式会社 Can通信システム
JP2007060400A (ja) * 2005-08-25 2007-03-08 Auto Network Gijutsu Kenkyusho:Kk 通信タイミング制御方法および通信タイミング制御システム
JP5019936B2 (ja) * 2007-04-13 2012-09-05 株式会社オートネットワーク技術研究所 車載用中継接続ユニット

Also Published As

Publication number Publication date
JP2012204932A (ja) 2012-10-22

Similar Documents

Publication Publication Date Title
JP5671388B2 (ja) 通信システムおよび通信装置
US8934351B2 (en) Communication apparatus and communication system
US10153825B2 (en) Vehicle-mounted control device
JP2011192068A5 (ja) プログラマブルコントローラおよびマスタ通信回路
JP5050653B2 (ja) 電子制御装置
JP5637193B2 (ja) 通信システム
JP5671390B2 (ja) 通信装置および通信システム
JP5671389B2 (ja) 通信装置および通信システム
JP5723189B2 (ja) 通信装置および通信システム
JP5409681B2 (ja) 通信システム
JP4465905B2 (ja) 電子制御装置
JP4737049B2 (ja) 通信システム及び電子制御装置
US5636343A (en) Microcomputer with built-in serial input-output circuit and collision detection circuit responsive to common input-output line being occupied
CN112583678B (zh) 接收方装置、发送方装置以及用于时钟同步的方法
CN113170500B (zh) 一种信息传输方法及装置
CN111026694B (zh) 数据接收方法、设备,图像形成装置、系统和电子设备
JP4361540B2 (ja) ゲートウェイ装置、データ転送方法及びプログラム
CN114928511A (zh) 数据处理设备及数据处理系统
US8427955B2 (en) Method and apparatus for transferring data
CN114884768B (zh) 一种总线空闲状态的检测装置、系统及检测方法
JP2012114724A (ja) 電子制御装置
CN111338680B (zh) 从站的固件升级方法、固件升级装置及终端
Shokry et al. Hardware EDF scheduler implementation on controller area network controller
Mansour Optimization of SPI protocol in precision farming environment
CN111124987B (zh) 一种基于pcie的数据传输控制系统和方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130422

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131009

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131015

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131105

R150 Certificate of patent or registration of utility model

Ref document number: 5409681

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees