JP2012239143A - 電子制御ユニット、車載ネットワーク、データ送信方法 - Google Patents

Abstract

【課題】通信データを周期的に送信する電子制御ユニットにイベントが生じても、送信タイミングの衝突を回避できる電子制御ユニットを提供すること。
【解決手段】通信データ毎に予め定められた周期で複数の通信データを周期的に送信する電子制御にユニット１００であって、オフセット時間記憶手段１４と、通信データの送信を伴うイベントを検出するイベント検出手段１２と、前記オフセット時間オフセットして前記周期で各通信データを周期的に送信し、前記イベント検出手段がイベントを検出した際にイベント通信データを送信する送信手段１１と、送信手段がイベントの発生によりイベント通信データを送信した場合、イベント通信データと同種の情報が含まれる同種通信データを最後に周期的に送信した送信タイミングを基準に、前記周期を変更せずに前記同種通信データの前記周期の起点を決定する送信タイミング決定手段１３と、を有することを特徴とする。
【選択図】図２

Description

本発明は、複数の通信データを送信する電子制御ユニットに関し、特に、通信データの衝突を回避できる電子制御ユニット等に関する。

車両には車載装置を制御するための各種の電子制御ユニット（以下、ＥＣＵという）が搭載されており、各ＥＣＵは互いに通信することで種々の処理を実行している。ＥＣＵ間の通信の通信規格としてＣＡＮプロトコルやＦｌｅｘＲａｙプロトコル等が知られているが、いずれも各ＥＣＵがバスを共有する時分割多重通信である。このため、ＣＡＮプロトコルでは、ＣＡＮバスの使用権を調停するためにＣＳＭＡ／ＣＤを採用して、同時に複数のＥＣＵが送信を開始した場合、アービトレーションフィールドのＩＤの優先度が最も高いＥＣＵだけがＣＡＮバスを使って通信データを送信することができる。優先度の低いＥＣＵは所定時間をおいて送信する。

また、複数のＥＣＵが送信する場合だけでなく、１つのＥＣＵが複数の通信データを送信する場合も少なくない。例えば、複数のＥＣＵの機能が１つに統合されたＥＣＵでは、複数の通信データをＣＡＮバスに出力する必要があり、ＥＣＵ内で共有リソースの使用権の調停などが必要になる送信タイミングの衝突が発生することがある。

従来から送信タイミングの衝突を低減する技術が考案されている（例えば、特許文献１参照。）。特許文献１には、各ＥＣＵから送信される周期的メッセージの送信時間を集計して、各ＥＣＵから送信されるメッセージが他のＥＣＵから送信されるメッセージの送信開始時点から送信終了時点までの時間と重ならないように送信タイミングを調整する車両用通信制御ユニットが開示されている。

特開２００７−１８４８３３号公報

しかしながら、特許文献１に記載された車両用通信制御ユニットでは、イベントの発生による送信タイミングのずれに対応できないという問題がある。また、特許文献１では、一台のＥＣＵ内部の送信タイミングの衝突について考慮されてない。

図１は、送信タイミングのずれについて説明するための図の一例である。一例として、ＥＣＵは３つの通信データＡ〜Ｃを周期的に送信するものとし、通信データＡは１００ミリ秒周期、通信データＢは２００ミリ秒周期、通信データＣは３００ミリ秒周期であるとする。
（１）このようにあるＥＣＵが周期的に異なる通信データを送信する場合、周期の最小公倍数が経過するタイミングで内部的に送信タイミングが衝突してしまう。例えば、通信データＢの周期は通信データＡの周期の２倍、通信データＣの周期は通信データＡの周期の３倍となっているので、通信データＡにとっては２００ミリ秒毎と３００ミリ秒毎に送信タイミングが衝突する。

このため、ＥＣＵは、例えば、周期の大きい方の通信データの送信タイミングをオフセットする。ＥＣＵは、周期Ｂの送信タイミングが到来してからオフセット時間遅らせて通信データＢを送信し、周期Ｃの送信タイミングが到来してからオフセット時間遅らせて通信データＣを送信する。
（２）次に、ＥＣＵになんらかのイベントが発生し、１００ｍｓ周期と異なるタイミング（最後に周期的に通信データＡを送信してからｘミリ秒後）に通信データＡ´を送信したとする。この場合、ＥＣＵは通信データＡ´を送信したタイミングで時間の計測をゼロにするので、通信データＡ´の送信タイミングから１００ｍｓ周期の通信データＡの送信を再開する。

しかし、このような通信データＡの周期の起点のずれは、通信データＡと、通信データＢ又Ｃとの送信タイミングの衝突の可能性を生じさせる。図では、通信データＡの送信タイミングとオフセット後の通信データＣの送信タイミングが衝突している。

したがって、ＥＣＵにイベントが発生し、イベントによりいずれかの通信データの送信タイミングがずれると、送信タイミングが衝突するおそれが生じてしまう。

本発明は、上記課題に鑑み、通信データを周期的に送信する電子制御ユニットにイベントが生じても、送信タイミングの衝突を回避できる電子制御ユニットを提供することを目的とする。

本発明は、 通信データ毎に予め定められた周期で複数の通信データを周期的に送信する電子制御にユニットであって、各通信データのオフセット時間を記憶するオフセット時間記憶手段と、通信データの送信を伴うイベントを検出するイベント検出手段と、前記オフセット時間オフセットして前記周期で各通信データを周期的に送信し、前記イベント検出手段がイベントを検出した際にイベント通信データを送信する送信手段と、前記送信手段がイベントの発生によりイベント通信データを送信した場合、イベント通信データと同種の情報が含まれる同種通信データを最後に周期的に送信した送信タイミングを基準に、前記周期を変更せずに前記同種通信データの前記周期の起点を決定する送信タイミング決定手段と、を有し、前記送信手段は、前記イベント通信データを送信した後、前記送信タイミング決定手段が決定した前記周期の起点から前記同種通信データの送信を再開する、ことを特徴とする。

通信データを周期的に送信する電子制御ユニットにイベントが生じても、送信タイミングの衝突を回避できる電子制御ユニットを提供することができる。

送信タイミングのずれについて説明するための図の一例である。 電子制御ユニットによる送信タイミングの制御を説明するための図の一例である。 車載ネットワークの概略構成図の一例である。 ＥＣＵのハードウェア構成図の一例である。 オフセットの態様のいくつかの例を説明する図の一例である。 ＥＣＵの機能ブロック図の一例である。 周期の起点の演算について説明する図の一例である。 イベント発生時に各ＥＣＵ１００が周期の起点を元に戻す手順の一例を示すフローチャート図である。 イベントデータと通信データＣの衝突について説明する図の一例である。 イベントデータと通信データＣの衝突について説明する図の一例である。 本実施形態の車載ネットワーク２００による送信タイミングの制御を説明するための図の一例である。 車載ネットワークの機能ブロック図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。

図２は、本実施形態の電子制御ユニットによる送信タイミングの制御を説明するための図の一例である。電子制御ユニット（以下、ＥＣＵ：Electronic Control Unit）は通信データＡ〜Ｃをそれぞれ周期的に送信している。各通信データの周期は以下のようになっている。
通信データＡ（１００ミリ秒）
通信データＢ（２００ミリ秒）
通信データＣ（３００ミリ秒）
したがって、通信データＡと通信データＢ、通信データＡと通信データＣが比較的短時間に衝突を繰り返す（通信データＢとＣについても衝突しうるが、詳しくは後述する）。そこで、ＥＣＵ１００は、通信データＢとＣの送信タイミングが通信データＡと衝突しないように、送信タイミングをオフセットする。オフセット時間については後述する。図では通信データＢ，Ｃのオフセット時間をそれぞれオフセット時間Ｂ，Ｃとしている。

ＥＣＵ１００に通信データの送信タイミングを異ならせるイベントが発生したとする。このため、ＥＣＵ１００は、周期Ａに基づく通信データＡの最後の送信タイミング＋ｘミリ秒で通信データＡ´（以下、イベントデータという）を送信する。このｘミリ秒はイベントの発生タイミングに依存するため不定である。

本実施形態のＥＣＵ１００は、イベントが発生することで通信データＡの送信タイミングが元の周期の送信タイミングからずれると、周期の起点を元に戻す。すなわち、ＥＣＵ１００がイベントデータを送信した「送信タイミング＋ｘ」ミリ秒から１００ミリ秒の周期を刻むのではなく、イベントデータの送信タイミングから「１００−ｘ＋１００」ミリ秒から１００ミリ秒の周期を刻む。よって、通信データＡの周期の起点は周期を変えることなく元に戻り、他の通信データＢ、Ｃの送信タイミングと衝突することを回避できる。

〔構成〕
図３は、車載ネットワーク２００の概略構成図の一例を示す。車載ネットワーク２００は、ＥＣＵ１００を電気的に接続し、所定のプロトコルに基づき、通信データの送信を可能にしている。図ではＥＣＵ１００が３個接続されているが、２個だけ接続されていてもよいし、４個以上接続されていてもよい。

車載ネットワーク２００のプロトコルには、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、ＦｒｅｘＲａｙ等があるが、バスを共有した時分割多重通信であることが多い。このため、各ＥＣＵはプロトコルに従いバスの使用権を得て通信データを送信する。本実施形態では、各ＥＣＵはＣＡＮプロトコルにより通信するものとする。

ＥＣＵ_Ａ〜ＥＣＵ_Ｃは、例えばボディ系、制御系、情報・ＡＶ系等、系統別にゲートウェイで区分されたネットワーク内のＥＣＵである。ボディ系であればドアＥＣＵ、パワーシートＥＣＵ、ライトＥＣＵ、エアコンＥＣＵ、メータＥＣＵ、制御系であればエンジンＥＣＵ、ブレーキＥＣＵ、エアバッグＥＣＵ、情報・ＡＶ系であればナビＥＣＵ、ＡＶ用ＥＣＵ等がある。ＥＣＵ_Ａ〜ＥＣＵ_Ｃの１つ以上がゲートウェイでもよく、また、ゲートウェイ機能が統合されたＥＣＵでもよい。本実施例ではこのうちの１つのＥＣＵ１００による複数の通信データＡ〜Ｃの送信タイミングの衝突の回避について説明していることに注意されたい。

図４は、ＥＣＵ１００のハードウェア構成図の一例を示す。ＥＣＵ１００はマイコン５０とその他の回路とを有し、その他の回路は主に電源ＩＣ２１、入出力Ｉ／Ｆ２２、不揮発メモリ２３、監視回路２４、及び、クロック生成器２５である。

また、マイコン５０はＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３、ＩＮＴＣ（割込みコントローラ）３４、不揮発メモリ３５、ＤＭＡＣ３６、及び、ブリッジ３７を有する。ＣＰＵ３１は、例えばＲＯＭ３３に記憶されたプログラムを実行しＲＡＭ３２にデータを書き込み、またＲＡＭ３２に書き込まれたデータを読み出して演算結果を生成したり、他のＥＣＵ１００と通信するための通信情報を生成する。ＲＡＭ３２はこのようなプログラムの作業メモリとなり、各種のデータが一時的に記憶される。

ＲＯＭ３３にはプログラムが予め記憶されている。また、プログラムはＥＣＵ１００に特有の処理を行うものの他、通信データの衝突を回避するためのプログラムが含まれている。このようなプログラムは通信ソフトと一体に構成されることが多い。ＩＮＴＣ３４は、入出力Ｉ／Ｆ２２、不図示のタイマ、又は、他のＥＣＵ等からの割込み要因を調停して、ＣＰＵ３１に割込み要求する。不揮発メモリ３５は、フラッシュメモリなどのＥＥＰＲＯＭであり省電力モード移行時にデータの退避に使用される。ＤＭＡＣ３６は、入出力Ｉ／Ｆ２２からの要求を受け付けて入出力Ｉ／Ｆ２２からＲＡＭ３２の指定アドレスにデータを転送し、また、ＣＰＵ３１からの要求を受け付けてＲＡＭ３２の指定アドレスから入出力Ｉ／Ｆ２２にデータを転送する。ブリッジ３７は、マイコン内のバス１８とマイコン５０外のバス２６の周波数の違いや電圧の違いを吸収してバス同士を接続する。

電源ＩＣ２１は、不図示のバッテリから電力供給を受けてマイコン駆動用の電圧・電流を生成する。ＩＧオン時は、ＥＣＵ内の全ての回路を通常モードで動作させるために必要な大容量の電圧・電流を生成し、ＩＧオフ時は、マイコン５０や他の回路の一部を省電力モードに保持するために必要な最小限の電圧・電流を生成する。電源ＩＣ２１は、通常モードと省電力モードにおいて、予めそれぞれに決められた回路に電力を供給する。

入出力Ｉ／Ｆ２２にはマイコン５０が演算に用いる信号を検出する各種のセンサ、マイコン５０が制御するアクチュエータやアクチュエータのドライバ回路等が接続されている。ＣＡＮ通信装置２３は、ＣＡＮプロトコルに従って他のＥＣＵ等と通信する装置である。

クロック生成器２５はマイコン５０に動作クロックを供給する。クロック生成器２５は、スリープモードになると、クロックを停止するか通常モードよりも低速にし、また、ＣＰＵ（又は一部）やＣＡＮ通信装置２３など、通常モードに復帰するための移行条件の成立を検出するための回路以外へのクロック供給を停止して消費電力を抑制する。

監視回路２４は、異常を検出するためのウォッチドックタイマ、異常時にマイコン５０をリセットして再起動させるためのリセット回路等を有する。

〔オフセットの態様〕
まず、オフセット対象の通信データについて説明する。１つのＥＣＵ１００はイグニッションオンやウェイクアップによる起動後、周期的な通信データの送信を開始する。このため、各通信データの周期の起点は“ＥＣＵの起動時”という共通のタイミングになる。複数の通信データの周期的な送信の起点が共通なため、ある通信データの送信タイミングは他の通信データと周期の最小公倍数の時間が経過する毎に衝突する。したがって、理論上は、１つの通信データを除き、全ての通信データにオフセットを設ける必要が生じてしまう。しかし、ＥＣＵ１００に負荷を掛けるのは頻繁な衝突であるので、例えば開発者は以下のようにオフセット対象の通信データを選別することができる。

例えば、周期の最小公倍数が所定値未満の場合、頻繁に衝突が発生することになるので、最小公倍数が所定値未満の周期の通信データのいずれか一方をオフセットすると決定すればよい。例えば、通信データＡの周期が１００ミリ秒、通信データＢの周期が２００ミリ秒の場合、最小公倍数は２００ミリ秒、通信データＡの周期が１００ミリ秒、通信データＣの周期が３００ミリ秒の場合、最小公倍数は３００ミリ秒、通信データＡの周期が１００ミリ秒、通信データＤの周期が１５０ミリ秒の場合、最小公倍数は３００ミリ秒、通信データＡの周期が１００ミリ秒、通信データＥの周期が１３０ミリ秒の場合、最小公倍数は１３００ミリ秒である。上限の最小公倍数を例えば１０００ミリ秒としておけば、通信データＢ〜Ｄの送信タイミングがオフセットされることになる。

図５は、オフセットの態様のいくつかの例を説明する図の一例である。図５（ａ）では、周期の長い通信データＢが、本来の周期の送信タイミングからオフセット時間Ｂオフセットされた時刻に送信されている。周期の短い通信データＡは優先順位が高いことが多いので、周期の長い通信データＢの送信タイミングをオフセットすることで、通信データＡの送信タイミングをオフセットすることを防止できる。また、通信データＡ、Ｂを受信する他のＥＣＵも、周期が長い通信データＢについては受信タイミングのずれを比較的許容しやすいので、オフセットがもたらす影響を抑制しやすい。

図５（ｂ）では、ＥＣＵ１００は、周期の短い通信データＡを本来の周期の送信タイミングからオフセット時間Ａオフセットした時刻に送信している。何らかの理由で、通信データＢ又は通信データＣの送信タイミングをオフセットしにくい場合、周期の短い通信データＡの送信タイミングをオフセットすることも有効である。

図５（ｃ）では、複数の通信データが本来の周期の送信タイミングからオフセット時間オフセットされた時刻に通信データを送信している。通信データＢのオフセット時間はオフセット時間Ｂ、通信データＣのオフセット時間はオフセット時間Ｃである。図ではオフセット時間Ｂ＜オフセット時間Ｃであるが、オフセット時間Ｂ＞オフセット時間Ｃとすることも可能である。しかし、この場合も、他のＥＣＵにとって、周期が長い通信データＣの受信タイミングのずれは比較的許容しやすいので、オフセット時間Ｂ＜オフセット時間Ｃとする方が、オフセットがもたらす影響を抑制しやすい。

オフセット時間は、通信データのバス使用時間を下限に、周期の例えば十分の一を上限とする。すなわち必要最小限とすればよい。通信データを受信して利用するＥＣＵ１００にとって、オフセット時間は短い方が好ましいためである。

バス使用時間は、プロトコルにしたがって算出することができる。ＣＡＮの場合、通信データはフレームという単位で送信され、１つのフレーム（データフレームの場合）は、ＳｏＦ、ＣＡＮＩＤ、ＲＴＲ、コントロールフィールド、データフィールド、ＣＲＣ、ＡＣＫ、ＥｏＦの各フィールドを有する。ＳｏＦはリセッシブ（Ｈｉｇｈ）からドミナント（Ｌｏｗ）に変化したタイミングであり、ＥＯＦは7ビット長のリセッシブ固定である。したがって、ＳｏＦからＥｏＦまでのビット数をカウントすることで、通信データのバス使用時間を計測できる。データフィールド以外の各フィールドのビット長は固定であるが、データフィールドは０〜６４ビットである。このため、バス使用時間を算出する場合、通信データの１フレームの最大長を想定して算出してもよいし、オフセットされる通信データ毎にデータフィールドのビット長を求め個別に算出してもよい。

例えば、ＣＡＮの通信速度を５００ｋｂｐｓとすれば、１ビットの長さは１／５０００００＝２マイクロ秒である。したがって、データフィールドを６４ビットとするか又は通信データＡのデータフィールドのビット長から１フレーム全体のビット長を求め、２マイクロ秒を乗じることで、バス使用時間を算出できる。なお、実際には通信処理のオーバーヘッドを考慮して数ミリ秒（例えば１〜１０秒程度）を１つのオフセット時間とする。以下、説明のため、一単位のオフセット時間は固定であるとする。

なお、各通信データのオフセット時間はプログラムにより決定することができ、このプログラムの実行は車両に搭載する前に完了させることができる。しかしながら、車載されたＥＣＵ１００が計算することも可能であるので、説明上はＥＣＵ１００が決定するとして説明する。
・図５（ａ）の場合、ＥＣＵ１００は、通信データＢの送信タイミングを１オフセット時間オフセットする。
・図５（ｂ）の場合、ＥＣＵ１００は、通信データＡの送信タイミングを１オフセット時間オフセットする。
・図５（ｃ）の場合、ＥＣＵ１００は送信周期の短い順に（優先順位の高い順に）通信タイミングをオフセットする。

図５（ｃ）を例にオフセット時間の決定について詳細に説明する。
(i)まず、ＥＣＵ１００は周期的に送信する全ての通信データの周期を取得し、最も周期の短い通信データＡを固定して他の通信データＢ，Ｃとの組における最小公倍数を計算する。ＥＣＵ１００は、通信データＡは最も周期が短いので、通信データＡはオフセットしない。通信データＡとＢの周期の最小公倍数は２００ミリ秒、通信データＡとＣの周期の最小公倍数は３００ミリ秒である。したがって、例えば通信データＢとＣがオフセットの対象となる。
(ii)次に、ＥＣＵ１００は通信データＢの送信タイミングを１オフセット時間オフセットする。
(iii)次に、ＥＣＵ１００は、通信データＣの送信タイミングを１オフセット時間オフセットする。
(iv)通信データＢとＣを同じ時間オフセットしたので、通信データＢとＣは送信タイミングが衝突したままである。このため、ＥＣＵ１００は、次に周期の短い通信データＢを固定して、他の通信データＣとの組における最小公倍数を計算する。最小公倍数は６００ミリ秒である。通信データＢは最も周期が短いので、通信データＢはオフセットしない。
(v)ＥＣＵ１００は、通信データＣの送信タイミングを１オフセット時間オフセットする。したがって、通信データＣは合計２オフセット時間オフセットされる。

このような処理を周期の短い順に繰り返すことで、周期の短い通信データを優先しながら、各通信データのオフセット時間を決定することができる。

〔機能ブロック図〕
図６は、ＥＣＵ１００の機能ブロック図の一例である。各ＥＣＵ１００は、周期毎送信部１１、イベント検出部１２、送信周期演算部１３、及び、オフセット時間保持部１４を有する。各機能は、ＣＰＵ３１がプログラムを実行すると共にハードウェアと協働することで実現される。

周期毎送信部１１は、自ＥＣＵ１００が他のＥＣＵ１００に提供すべき通信データを周期的に送信する。周期毎送信部１１は、通信データ毎に決まっている周期で通信データ毎に独立に通信データを送信する。すなわち、周期毎送信部１１は、通信データＡを送信するとソフト的なタイマをリセットし１００ミリ秒の経過毎に、通信データＡの送信とタイマのリセットを繰り返す。通信データＢについては、通信データＢを送信するとソフト的なタイマをリセットし、２００＋オフセット時間Ｂミリ秒の経過毎に、通信データＢの送信とタイマのリセットを繰り返す。通信データＣについては、通信データＣを送信するとソフト的なタイマをリセットし、３００＋オフセット時間Ｃミリ秒の経過毎に、通信データＣの送信とタイマのリセットを繰り返す。

なお、通信データＡ〜Ｃの内容は値は変化しうるがある決まった物理量であり、イベントの発生により送信されるイベントデータも物理量としては通信データＡ〜Ｃのいずれかになる。通信データの内容は、例えば、車速データ、時刻データ、等である。周期毎送信部１１は、例えば、ＩＧ（イグニション）オン又はウェイクアップ端子の立ち上がりを起点に周期的な通信データの送信を開始する。

周期の起点は、複数の通信データに共通である。共通であるので周期の最小公倍数で送信タイミングの衝突が生じ得るが、本実施例では送信タイミングにオフセットを設けているので衝突することはない。また、例えば、周期の起点をランダムにずらすと、バスの空き時間が細切れになるが、周期の起点を複数のＥＣＵ１００に共通にして、かつ、送信タイミングにオフセットを設けることで、バスの使用効率を向上させることができる。

なお、周期毎送信部１１は周期的に通信データを送信する度に、周期の起点の再設定のため、送信タイミングを送信周期演算部１３に送出する。この送信タイミングは、例えば、時刻でもよいし、ソフト的又はハード的なタイマのカウント値でもよい。

オフセット時間保持部１４は、上記のように決定された通信データ毎のオフセット時間を保持している。オフセット時間保持部１４は、保持しているオフセット時間を周期毎送信部１１に送出する。これにより、周期毎送信部１１は、予め定められた周期が到来してからオフセット時間待機した後、通信データを送信できる。

イベント検出部１２は、例えば入出力Ｉ／Ｆなどの割り込みによりＥＣＵ１００に生じたイベントを検出して、イベント内容を周期毎送信部１１に通知する。

周期毎送信部１１は、周期的に送信する通信データ以外に、発生したイベントに応じて、イベントデータを不定期に送信する。イベントには様々なものがありまたＥＣＵ１００によっても異なるが、例えば、運転者の各種の操作（ブレーキペダルの踏み込み・踏み戻し、アクセルペダルの踏み込み・踏み戻し、シフトポジションの変更、ステアリングの操作…）、スマートキーの認証、ドアのロック・アンロックなどがある。

イベントデータは、通信データＡ、通信データＢ、通信データＣのいずれかと同じ物理量（以下、同種という）の場合と、通信データＡ〜Ｃと異なる場合があるが、本実施例では同種の場合を扱う。例えば、通信データＡがアクセル開度の場合、ユーザがアクセルペダルを操作したためＥＣＵ１００がアクセル開度をイベントデータとして送信するような場合、通信データＡとイベントデータは同種になる。

なお、周期毎送信部１１はイベントデータを送信すると、周期の起点の再設定のため、送信タイミング（上記のｘミリ秒）を送信周期演算部１３に送出する。

そして、送信周期演算部１３は周期毎送信部１１がイベントデータを送信したことで、自ＥＣＵ１００の通信データの送信タイミングが変更しないように周期の起点を演算する。

図７は、周期の起点の演算について説明する図の一例である。周期毎送信部１１が最後に通信データＡを送信した送信タイミングと、周期毎送信部１１が通信データＡと同種のイベントデータを送信した送信タイミングの時間差がｘミリ秒であったとする。この場合、次回の周期的な送信の送信タイミングはイベントデータの送信から「１００−ｘ」ミリ秒経過した時である。

しかし、ｘミリ秒が送信周期である１００ミリ秒に近い場合（例えば、９５ミリ秒以上）に、例えばバッファに記憶されて送信待ちになっているイベントデータが周期的な送信用の通信データに上書きされるおそれがある。このため、周期毎送信部１１はイベントデータの送信から「１００−ｘ」ミリ秒経時の周期の到来時に通信データＡを送信しない。すなわち、周期毎送信部１１は周期の到来を１回無視する（飛ばす）。

よって、次回の送信タイミングは、「１００−ｘ＋１００ミリ秒」である。すなわち、送信周期演算部１３は、「１００−ｘ＋１００ミリ秒」を周期の次の起点として、周期毎送信部１１に通知する。イベントデータの送信直後に周期毎送信部１１はタイマをリセットしているので、周期毎送信部１１はイベントデータの送信時から「１００−ｘ＋１００ミリ秒」経過後に周期的な通信データＡの送信を再開できる。例えば、ｘが５０ミリ秒とすると、「１００−５０＋１００ミリ秒＝１５０ミリ秒」となるので、これが次回の送信タイミングであると共に周期の起点となる。なお、イベントデータが通信データＢ，Ｃと同種の場合も同様であるが、通信データＢ，Ｃの場合はそれぞれオフセット時間Ｂ、Ｃオフセットされる。

〔動作手順〕
図８は、イベント発生時に各ＥＣＵ１００が周期の起点を元に戻す手順の一例を示すフローチャート図である。図８の手順は、イグニッションオンなどによりＥＣＵ１００が起動するとスタートする。

起動後、オフセット時間保持部は周期毎送信部１１に通信データＡ（オフセット時間はゼロ）、通信データＢ、Ｃのオフセット時間を設定する（Ｓ１０、Ｓ２０）。

イベント検出部１２はイベントが発生したか否かを監視している（Ｓ３０、Ｓ４０、Ｓ５０）。イベントが発生しない場合（Ｓ３０〜５０のＮｏ）。周期毎送信部１１は通信データＡをオフセットせずに周期的に送信し、通信データＢをオフセット時間Ｂオフセットして周期的に送信し、通信データＣをオフセット時間Ｃオフセットして周期的に送信する（Ｓ７０）。

イベント検出部１２がイベントの発生を検出した場合（Ｓ３０〜５０のＹｅｓ）、周期毎送信部１１はイベントに応じたイベントデータを送信する（Ｓ６０）。

そして、送信周期演算部１３は周期毎送信部１１がイベントデータを送信すると、周期の起点を演算して周期毎送信部１１に通知する（Ｓ８０）。周期毎送信部１１は、通知された周期の起点に、必要であれば（通信データＢ，Ｃの場合）オフセット時間を加えて周期的に通信データを送信する。

以上説明したように、本実施例のＥＣＵ１００は、イベントが発生しても、周期に基づく送信タイミングを変更せずに周期的な通信データの送信を再開することができる。衝突を検知して送信タイミングをずらすことがないので、衝突の頻度を抑制できＥＣＵ１００の負荷が増大することを防止できる。

実施例１では、ＥＣＵ１００がイベントに応じてイベントデータを送信できると説明した。この場合、イベントデータが通信データＡと同種であれば、イベントデータと通信データＡとが衝突するおそれはない。しかし、通信データＡと同種のイベントデータは通信データＢ，Ｃと衝突するおそれがある。本実施例では、イベントデータが他の通信データと衝突しないＥＣＵについて説明する。

図９は、イベントデータと通信データＣの衝突について説明する図の一例である。図示するようにイベントデータの送信タイミングが通信データＣの送信タイミングと衝突している。送信タイミングが衝突すると、ＥＣＵ内で例えばバスや共有リソースの調停が始まるため、ＥＣＵ１００の負荷が増大する。そこで、本実施例のＥＣＵ１００は、イベントが検出された場合、他の通信データの送信を１周期、遅らせる（飛ばす）。こうすることで、イベントデータと通信データが衝突する可能性を極めて小さくすることができ、また、他の通信データの周期の起点が狂うことも防止できる。

このため、本実施例の送信周期演算部１３は、イベント検出部１２から検出されたイベント内容に基づき、イベントデータと同種の通信データを特定し、イベントデータと同種の通信データ以外の通信データの周期の起点を演算する。イベントデータと同種の通信データについては実施例１と同様である。

例えば、通信データＡと同種のイベントデータが送信される場合、送信周期演算部１３は通信データＢとＣの周期の起点を演算する。すなわち、実際に衝突するか否かは問わない。
・通信データＢの場合
イベントデータの送信タイミングにおいて、周期毎送信部１１が最後に通信データＢを送信してからｘ_ｂ秒が経過している場合、通信データＢの周期の起点は、通信データＢの送信タイミングから「２００＋２００ミリ秒」経過した時である。
・通信データＣの場合
同様に、通信データＣの周期の起点は、通信データＣの送信タイミングから「３００＋３００ミリ秒」経過した時である。

このように、通信データＢ、Ｃの周期の起点は、イベントデータの送信タイミングの影響を受けず、一度だけ周期を２倍することで求められる。

送信周期演算部１３はこのように演算した周期の起点を周期毎送信部１１に通知する。周期毎送信部１１は、最後に通信データＢ，Ｃを送信した時を基準にソフト的なタイマで時間を計測しているので、タイマの計測時間と演算された周期の起点を比較するだけで、通信データの送信を1周期、遅らせることができる。

以上説明したように、本実施例のＥＣＵは、実施例１の効果に加え、イベントデータが他の通信データと衝突する可能性を抑制できるので、ＥＣＵ１００の負荷が増大するおそれをさらに低減できる。

実施例２のように、ＥＣＵ１００が通信データＢ、Ｃの送信を１周期遅らせると、通信データＢ、Ｃが１周期より長い間、他のＥＣＵ１００に送信されなくなってしまう。周期の長い通信データは優先度が低いので不都合は少ないが、通信データＡと同種のイベントデータが頻繁に送信されると、２周期以上、通信データＢ，Ｃが送信されないおそれもある。そこで、本実施例では、通信データＢ，Ｃの送信を確保可能なＥＣＵ１００について説明する。

図１０は、イベントデータと通信データＢ，Ｃの送信について説明する図の一例である。実施例２と同様に、ＥＣＵ１００は、イベントが検出された場合、他の通信データＢ，Ｃの送信を１周期、遅らせる（飛ばす）。そして、他の通信データのいずれか１つをイベントデータと同種の通信データＡの送信タイミングで送信する。例えば、図の例ではイベントデータと同種の通信データＡが「１００−ｘ」ミリ秒の送信タイミングでは送信されないので、ＥＣＵ１００はこの送信タイミングに通信データＢ（又は通信データＣでもよい）を送信する。この送信タイミングは通信データＡに固有なので、通信データＢが通信データＡやＣと衝突するおそれはない。

なお、ＥＣＵ１００は、イベントデータの送信タイミングから「２００−ｘ_ｂ」ミリ秒の経過時、実施例２と同様、通信データＢを送信しない。そして、イベントデータの送信タイミングから「２００−ｘ_ｂ＋２００ミリ秒」経過した時に周期的な送信を再開する。

通信データＣについては、実施例１と同様になるが、次回、イベントが検出された場合、ＥＣＵ１００は、イベントデータと同種の通信データのタイミングで通信データＣを送信する。こうすることで、通信データＡと同種のイベントデータが頻繁に送信されても、通信データＢ，Ｃの送信を確保できる。以下、このような送信を代替送信という。

周期の起点の算出について説明する。本実施例の送信周期演算部１３は、イベントの検出時に、どの通信データを代替送信するかを決定するためのフラグを有している。このフラグはイベントの発生毎に順番に対応づけられる通信データが変わっていく（通信データＢ→Ｃ→Ｂ→Ｃ…）。または、通信データの優先度に応じて、イベントの発生毎に対応づけられる通信データが変わっていく。周期を優先度とするなら、通信データＢとＣは３：２の比で代替送信される（通信データＢ→Ｃ→Ｂ→Ｃ→Ｂ→Ｂ→Ｃ→Ｂ→Ｃ→Ｂ…）。

また、フラグはイベント内容毎に設けられるのでフラグａ〜フラグｃが存在する。例えば、イベントデータが通信データＡと同種の場合、通信データＢを代替送信するとフラグaは通信データＣに対応づけられ、通信データＣを代替送信するとフラグａは通信データBに対応づけられる。イベントデータが通信データＢと同種の場合、通信データＡを代替送信するとフラグｂは通信データＣに対応づけられ、通信データＣを代替送信するとフラグｂは通信データＡに対応づけられる。

送信周期演算部１３はフラグにより代替送信すべき通信データを特定し、その通信データの送信タイミングを決定する。
・通信データＢの場合
イベントデータの送信タイミングにおいて、通信データＢが最後に送信されてからｘ_ｂ秒が経過している。最後の通信データＡと通信データＢの送信タイミングの差は「ｘ−ｘ_ｂ」であるが、この差はオフセット時間Ｂである。したがって、代替送信の送信タイミングは、「１００−（ｘ−ｘ_ｂ）＝１００−オフセット時間Ｂ」である。なお、その次の通信データＢの送信タイミングは、「２００−（１００−オフセット時間Ｂ）＋２００」ミリ秒である。
・通信データＣの場合
代替送信の送信タイミングは、「１００−（ｘ−ｘ_ｃ）＝１００−オフセット時間Ｃ」である。なお、その次の通信データＣの送信タイミングは、「３００−（１００−オフセット時間Ｃ）＋３００」ミリ秒である。

送信周期演算部１３はこのように演算した周期の起点を周期毎送信部１１に通知する。周期毎送信部１１は、最後に通信データＢ，Ｃを送信した時を基準にソフト的なタイマで時間を計測しているので、タイマの計測時間と演算された周期の起点を比較するだけで、通信データＢを通信データＡ、Ｃと衝突しないタイミングで、又は、通信データＣを通信データＡ、Ｂと衝突しないタイミングで代替送信できる。

以上説明したように、本実施例のＥＣＵは、実施例１、２の効果に加え、通信データＢ，Ｃの送信も確保することができる。

実施例１では、１つのＥＣＵ内の複数の通信データの衝突について説明したが、ネットワークを介して接続された複数のＥＣＵの通信データにおいても衝突しないように、周期の起点を元に戻すことができる。

図１１は、本実施形態の車載ネットワーク２００による送信タイミングの制御を説明するための図の一例である。ＥＣＵ_Ａ〜ＥＣＵ_Ｃはそれぞれ周期的に通信データを送信している。各ＥＣＵの周期は以下のようになっている。
ＥＣＵ_Ａ（１００ミリ秒）、ＥＣＵ_Ｂ（２００ミリ秒）、ＥＣＵ_Ｃ（３００ミリ秒）
このような周期では、ＥＣＵ_ＡとＥＣＵ_Ｂの送信タイミングが２００ミリ秒毎に、ＥＣＵ_ＡとＥＣＵ_Ｃの送信タイミングが３００ミリ秒毎に、それぞれ衝突してしまう。そこで、ＥＣＵ_ＢとＥＣＵ_Ｃは送信タイミングが衝突しないように、送信タイミングをオフセットしている。通信データＢ，Ｃの送信主体がＥＣＵ_Ｂ、ＥＣＵ_Ｃに分散しただけで、オフセットの態様は実施例１と同様である。

ＥＣＵ_Ａに通信データの送信タイミングを異ならせるイベントが発生したとする。このため、ＥＣＵ_Ａは、周期Ａの「最後の送信タイミング＋ｘ」ミリ秒で通信データＡ´を送信する。このｘミリ秒はイベントの発生タイミングに依存するため不定である。

本実施形態のＥＣＵ_Ａは、イベントが発生して通信データＡの送信タイミングが元の周期からずれると、周期を元に戻す。すなわち、ＥＣＵ_Ａが通信データＡ´（以下、イベントデータという）を送信した「周期Ａの最後の送信タイミング＋ｘ」ミリ秒から１００ミリ秒の周期を刻むのではなく、イベントデータの送信タイミングから「１００−ｘ＋１００」ミリ秒から１００ミリ秒の周期を刻む。よって、ＥＣＵ_Ａの周期の起点は元の周期のまま元に戻り、ＥＣＵ_Ｂ、ＥＣＵ_Ｃの送信タイミングと衝突することを回避できる。

図１２は、車載ネットワーク２００の機能ブロック図の一例である。図１２において図６と同一部の説明は省略する。各ＥＣＵが有する機能は実施例１と同様だが、周期毎送信部１１は自機のＥＣＵの通信データのみを送信し、オフセット時間保持部１４は自機の通信データのオフセット時間のみを保持している。その他の機能は実施例１と同じであり、例えば、送信周期演算部１３は周期毎送信部１１がイベントデータを送信したことで、自機のＥＣＵ１００の通信データの送信タイミングが変更しないように周期の起点を演算する。

本実施例によれば、複数のＥＣＵがオフセットしてそれぞれ周期的に通信データを送信する車載ネットワークにおいて、イベントが検出された場合、通信データが衝突する頻度を低減することができる。

１１ 周期毎送信部
１２ イベント検出部
１３ 送信周期演算部
１４ オフセット時間保持部
１００ 電子制御ユニット（ＥＣＵ）
２００ 車載ネットワーク

Claims (8)

1. 通信データ毎に予め定められた周期で複数の通信データを周期的に送信する電子制御にユニットであって、
   各通信データのオフセット時間を記憶するオフセット時間記憶手段と、
   通信データの送信を伴うイベントを検出するイベント検出手段と、
   前記オフセット時間オフセットして前記周期で各通信データを周期的に送信し、前記イベント検出手段がイベントを検出した際にイベント通信データを送信する送信手段と、
   前記送信手段がイベントの発生によりイベント通信データを送信した場合、イベント通信データと同種の情報が含まれる同種通信データを最後に周期的に送信した送信タイミングを基準に、前記周期を変更せずに前記同種通信データの前記周期の起点を決定する送信タイミング決定手段と、を有し、
   前記送信手段は、前記イベント通信データを送信した後、前記送信タイミング決定手段が決定した前記周期の起点から前記同種通信データの送信を再開する、
   ことを特徴とする電子制御ユニット。
2. 前記送信タイミング決定手段は、イベントの発生により送信されたイベント通信データの送信タイミングの直後の、前記同種通信データの周期の到来を無視し、２回目の周期の到来を前記同種通信データの周期の起点に決定する、
   ことを特徴とする請求項１記載の電子制御ユニット。
3. 前記イベント検出手段がイベントを検出した場合、
   前記送信タイミング決定手段は、イベントが検出されてから最初に周期的な送信タイミングが到来する、前記同種通信データ以外の通信データの送信を１回だけ中止する、
   ことを特徴とする請求項１又は２記載の電子制御ユニット。
4. 前記イベント検出手段がイベントを検出した場合、
   前記送信タイミング決定手段は、前記イベントが検出されてから前記同種通信データの最初の周期的な送信タイミングにおいて、前記同種通信データ以外の１つの通信データを送信する、
   ことを特徴とする請求項２記載の電子制御ユニット。
5. 前記送信タイミング決定手段は、前記同種通信データ以外に送信する１つの通信データを、
   同じ前記同種通信データが送信されるイベントが検出される毎に切り換える、
   ことを特徴とする請求項４記載の電子制御ユニット。
6. 前記同種通信データが最後に周期的に送信されてから、イベント通信データが送信されるまでの時間をｘ秒とすると、
   前記送信タイミング決定手段は、前記同種通信データの周期からｘ秒を減算し、さらに前記同種通信データの周期を加えた時間を、該同種通信データの周期の起点に決定する、
   ことを特徴とする請求項２記載の電子制御ユニット。
7. 複数の電子制御ユニットがネットワークを介して周期的に通信データを送信する車載ネットワークにおいて、
   各電子制御ユニットは、
   各通信データのオフセット時間を記憶するオフセット時間記憶手段と、
   通信データの送信を伴うイベントを検出するイベント検出手段と、
   前記オフセット時間オフセットして前記周期で各通信データを周期的に送信し、前記イベント検出手段がイベントを検出した際にイベント通信データを送信する送信手段と、
   前記送信手段がイベントの発生によりイベント通信データを送信した場合、イベント通信データと同種の情報が含まれる同種通信データを最後に周期的に送信した送信タイミングを基準に、前記周期を変更せずに前記同種通信データの前記周期の起点を決定する送信タイミング決定手段と、を有し、
   前記送信手段は、前記イベント通信データを送信した後、前記送信タイミング決定手段が決定した前記周期の起点から前記同種通信データの送信を再開する、
   ことを特徴とする車載ネットワーク。
8. 通信データ毎に予め定められた周期で複数の通信データを周期的に送信する電子制御にユニットのデータ送信方法であって、
   オフセット時間記憶手段に記憶された、各通信データのオフセット時間、オフセットして、送信手段が各通信データを周期的に送信する送信ステップと、
   通信データの送信を伴うイベントを検出するイベント検出ステップと、
   イベントが検出された際にイベント通信データを送信するステップと、
   前記送信手段がイベントの発生によりイベント通信データを送信した場合、イベント通信データと同種の情報が含まれる同種通信データを最後に周期的に送信した送信タイミングを基準に、前記周期を変更せずに前記同種通信データの前記周期の起点を決定する送信タイミング決定ステップと、
   前記送信手段が、前記イベント通信データを送信した後、前記送信タイミング決定ステップにより決定された前記周期の起点から同種通信データの送信を再開するステップと、
   有することを特徴とするデータ送信方法。

Images