(57)【要約】【課題】車両における複数のネットワーク間を接続するゲートウェイ装置において、データ転送の効率を向上させる。【解決手段】ＣＡＮとＬＩＮとの間でデータ転送を行うゲートウェイ装置では、ＣＡＮにおける受信タイミングを検出し、その受信タイミングの直後にＬＩＮにおける通信スケジュールが起動するようにその通信スケジュールの起動タイミングを調整する。ＬＩＮにおける通信スケジュールが、送信フレーム（の送信）、受信フレームの（受信）で構成される場合、ＬＩＮ通信スケジュールパターン（１１）のように、ＣＡＮにおける受信タイミングの直後にＬＩＮにおける通信スケジュールが起動すると、その通信スケジュールにてＣＡＮにて受信したデータが即座にＬＩＮに転送されるため、転送効率が向上する。【選択図】図２３
2010187323.tif 000002
【特許請求の範囲】
【請求項１】
車両内の複数のネットワークに接続されてそのネットワーク間でのデータ転送を行うゲートウェイ装置であって、少なくとも、
マスタ装置によって定期的に起動される通信スケジュールに従って、データの送受信が行われるネットワーク（以下、第１のネットワークと称する）と他のネットワーク（以下、第２のネットワークと称する）との間のデータ転送を行うゲートウェイ装置において、
マスタ装置として動作して通信スケジュールを起動するように構成され、
第１のネットワーク及び第２のネットワークを監視し、転送対象のデータが第１のネットワーク上で送受信される場合の送受信タイミング、及びその転送対象のデータが第２のネットワーク上で送受信される場合の送受信タイミングを検出する検出手段と、
検出手段の検出結果に基づき、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期するため、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するための通信スケジュールの起動タイミングを算出する算出手段と、を備え、
算出手段により算出された起動タイミングで通信スケジュールを起動するようになっていることを特徴とするゲートウェイ装置。
【請求項２】
請求項１に記載のゲートウェイ装置において、
転送対象のデータは複数種類あり、
その複数種類のデータには重要度を表す情報が含まれ、
検出手段は、複数種類のデータのうち重要度が最も高いデータについて、第１のネットワーク上での送受信タイミング、及び第２のネットワーク上での送受信タイミングを検出するようになっていることを特徴とするゲートウェイ装置。
【請求項３】
請求項１に記載のゲートウェイ装置において、
転送対象のデータは複数種類あり、
算出手段は、転送対象のデータの第２のネットワーク上における送受信タイミングの度数分布を算出し、その度数分布に基づき、第１のネットワーク上での送信のタイミングと第２のネットワーク上での受信のピークとが同期するため、或いは第１のネットワーク上での受信のタイミングと第２のネットワーク上での送信のピークとが同期するための通信スケジュールの起動タイミングを算出するようになっていることを特徴とするゲートウェイ装置。
【請求項４】
請求項１ないし請求項３の何れか１項に記載のゲートウェイ装置において、
通信スケジュールの起動タイミングを所定量づつ徐々に変更して算出手段により算出された起動タイミングに一致させることを特徴とするゲートウェイ装置。
【請求項５】
請求項１ないし請求項３の何れか１項に記載のゲートウェイ装置において、
転送対象のデータには緊急度を表す情報が含まれ、
緊急度を表す情報に基づき緊急を要するか否かを判断し、緊急を要すると判断すると、現在動作中の通信スケジュールを中止し、新たな通信スケジュールを起動するようになっていることを特徴とするゲートウェイ装置。
【請求項６】
請求項１ないし請求項５の何れか１項に記載のゲートウェイ装置において、
通信スケジュールの起動タイミングを変更した後、予め定められた時間が経過するまでは再度の変更を行わないようになっていることを特徴とするゲートウェイ装置。
【請求項７】
請求項１に記載のゲートウェイ装置において、
所定の転送対象のデータに代え、その転送対象のデータと同じタイミングでダミーデータの送受信を行うダミーデータ送受信手段を備え、
検出手段は、ダミーデータが第１のネットワーク上で送受信される場合の送受信タイミング、及びそのダミーデータが第２のネットワーク上で送受信される場合の送受信タイミングを検出し、
算出手段は、ダミーデータについて、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期するため、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するための通信スケジュールの起動タイミングを算出することを特徴とするゲートウェイ装置。
【請求項８】
請求項１ないし請求項７の何れか１項に記載のゲートウェイ装置において、
通信スケジュールの起動タイミングを変更することを表す情報を第１のネットワーク及び第２のネットワークの両方又は一方に送出するようになっていることを特徴とするゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載される車両ネットワークにおいて用いられ、その車両ネットワークにおける複数のネットワーク間を接続してデータの転送処理を行うゲートウェイ装置に関する。
【背景技術】
【０００２】
車両に搭載される車両ネットワークとしては、電子制御装置（以下、ＥＣＵと記載する）と、センサやアクチュエータとの間を１ないし複数本のワイヤハーネスで接続し、そのワイヤハーネスを介して、個々の仕様に応じた信号をやりとりするようにしたものがある。
【０００３】
車両においては制御の高度化・複雑化に伴いやりとりすべき情報量は増大傾向にあり、上記のような車両ネットワークではより多くのワイヤハーネスが必要となっていた。このため、搭載性が悪化したり重量やコストが増加したりしてしまうという問題があった。
そこで、近年では、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）などの多重通信ネットワークが利用される場合がある。ＣＡＮの通信仕様は、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｃｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式である。ＣＡＮでは、各通信装置（例えばＥＣＵ）は、通信バスが空いていれば即時にデータを送信することが可能である。
【０００４】
一方、ＬＩＮの通信仕様は、シングルマスタ／マルチスレーブ方式である。ＬＩＮでは、マスタが１台あり、そのマスタによるスケジューリングに従って通信が行われる。例えば、スレーブは、マスタの指示がないかぎりデータを送信することはできない。
【０００５】
図１９は、車両ネットワークの構成の一例を示す図面である。
【０００６】
図１９に示す車両ネットワーク３００は、ＥＣＵ３０１，３０２を備えている。そのＥＣＵ３０１，３０２は、周知のマイコンを備え、ＣＡＮ通信線３０７を介して接続され、ＣＡＮのプロトコルに従って通信可能なように構成されている。
【０００７】
また、ＥＣＵ３０１は、ワイヤハーネス３０４，３０５を介して制御対象としての制御装置３０３と接続される。そして、ＥＣＵ３０１は、ワイヤハーネス３０４，３０５を介して制御装置３０３との間でデータの送受信を行う。また、ＥＣＵ３０２は、ワイヤハーネス３０６を介して制御装置３０３と接続される。そして、ＥＣＵ３０２は、ワイヤハーネス３０６を介して制御装置３０３との間でデータの送受信を行う。図１９の例では、ワイヤハーネスは３本用いられている。
【０００８】
図２０は、ＣＡＮ及びＬＩＮを利用した車両ネットワークの構成の一例を示す図面であり、図１９におけるワイヤハーネス３０４，３０５，３０６による接続をＬＩＮ通信線４０４による接続に置き換え、ＬＩＮのプロトコルに従って通信するようにしたものである。
【０００９】
図２０に示す車両ネットワーク４００は、ＥＣＵ４０１，４０２を備えている。そのＥＣＵ４０１，４０２は、ＣＡＮ通信線４０５を介して互いに接続され、ＣＡＮのプロトコルに従って通信可能なように構成されている。
【００１０】
そして、ＥＣＵ４０１は、ＬＩＮ通信線４０４を介して制御対象としての制御装置４０３と接続され、そのＬＩＮ通信線４０４を介してＬＩＮのプロトコルに従って制御装置４０３との間でデータの送受信を行う。図２０のＬＩＮにおいて、ＥＣＵ４０１がマスタであり、制御装置４０３がスレーブである。
【００１１】
そして、図２０において、ＥＣＵ４０１は、ＣＡＮとＬＩＮとを接続するゲートウェイとしても機能し、ＣＡＮ上で例えばＥＣＵ４０２から受信したデータをＬＩＮに送ったり、ＬＩＮ上で例えば制御装置４０３から受信したデータをＣＡＮに送ったりする。ＥＣＵ４０２は、ＥＣＵ４０１を介して制御装置４０３と通信を行うこと、及びその制御装置４０３を制御することが可能である。尚、複数のネットワーク間を接続してデータを転送するようなゲートウェイ装置について、例えば特許文献１に記載されている。
【００１２】
ここで、図２１は、ＬＩＮにおいて送受信されるメッセージフレームの構成及びＬＩＮにおける通信のスケジュール（以下、単に通信スケジュールと記載する）の例を表す図である。尚、以下、ＬＩＮにおける通信のことを簡略化してＬＩＮ通信と記載する。ＣＡＮについても同様に、ＣＡＮにおける通信のことをＣＡＮ通信と記載することとする。
【００１３】
ＬＩＮ通信におけるメッセージフレームは、マスタによって初期化されたヘッダと、それに続くレスポンスとで構成される。マスタから定期的にヘッダが送出され、そのヘッダの内容に従って、マスタ或いはスレーブからレスポンスが送出される。
【００１４】
ヘッダは、図２１に示すように、Ｓｙｎｃｈ  Ｂｒｅａｋ（同期ブレーク）、Ｓｙｎｃｈ  Ｆｉｅｌｄ（同期フィールド）、及びＩｄｅｎｔ  Ｆｉｅｌｄ（識別子フィールド）の３つのフィールドで構成される。Ｓｙｎｃｈ  Ｂｒｅａｋ（同期ブレーク）はフレームの始まりを表す。Ｓｙｎｃｈ  Ｆｉｅｌｄ（同期フィールド）は、スレーブのボーレートの調整に用いられる。Ｉｄｅｎｔ  Ｆｉｅｌｄ（識別子フィールド）は識別子バイトを含んでいる。識別子バイトはメッセージフレームの目的を一意に定めるものである。
【００１５】
レスポンスは、図２１に示すように、Ｄａｔａ  Ｆｉｅｌｄ（データフィールド）、及びＣｈｅｃｋ  Ｓｕｍ（チェックサム）の２つのフィールドで構成される。Ｄａｔａ  Ｆｉｅｌｄ（データフィールド）は、具体的なデータを格納する。Ｃｈｅｃｋ  Ｓｕｍ（チェックサム）は、エラー検出の機能を果たす。
【００１６】
メッセージフレームは、マスタからスレーブへのデータが格納された送信フレームと、スレーブからマスタへのデータが格納された受信フレームとに区別される。
次に通信のスケジュールの例について説明する。図２１の例において、送信フレーム及び受信フレーム共にデータ量が４［ｂｙｔｅ］で、転送ボーレートが１９．２［ｋｂｐｓ］であるとすると、１つの送信フレーム或いは受信フレームの転送時間は約６．２［ｍｓｅｃ］となる。そして、送信フレーム及び受信フレームの２つのフレームの送受信で１つの通信スケジュール（以下、１スケジュールとも記載する）を構成するとした場合、マスタは、ヘッダを例えば８［ｍｓｅｃ］毎に送信すれば良い。この８［ｍｓｅｃ］という値は、上記の６．２［ｍｓｅｃ］に余裕分を含めたものである。このとき、１スケジュールの時間は１６［ｍｓｅｃ］となる。ところで、ＬＩＮでは、所定の周期で起動する定期タスクを基準にスケジュールが制御される。４［ｍｓｅｃ］の周期で起動する定期タスクで通信スケジュールを制御するとした場合、４周期毎（定期タスク４個毎）に１スケジュールが完了することとなる。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００６−３１９７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１８】
ここで、図２２は、ＣＡＮとＬＩＮとの間におけるデータの転送例を表す図である。具体的には、ＣＡＮからＬＩＮへのデータの転送例を表す。例えば、図２０においてＥＣＵ４０１がＣＡＮからＬＩＮにデータを転送する場合を想定する。
【００１９】
ＥＣＵ４０１は、ＣＡＮにおいて転送対象のデータを１６［ｍｓｅｃ］の周期で受信するとする。また、ＥＣＵ４０１がマスタとして動作するＬＩＮにおける定期タスクの周期が４［ｍｓｅｃ］であるとともに通信スケジュールの周期が１６［ｍｓｅｃ］であるとする。通信スケジュールは送信フレームの送受信と受信フレームの送受信とで構成される（図２１参照）ものとする。
【００２０】
ＥＣＵ４０１は、ＣＡＮにおいて受信したデータ１をＬＩＮに転送する場合、ＬＩＮにおける次の通信スケジュールの開始までＬＩＮにデータ１を転送することはできない。例えば、ＬＩＮにおける通信スケジュールの開始直後にＣＡＮにおいてデータ１を受信したとすると、ＬＩＮにそのデータ１を転送するためには、ＬＩＮにおける次の通信スケジュールまでのおおよそ１周期分（通信スケジュールの１周期分）、待たなくてはならない。
【００２１】
次に、図２３を用いて、ＣＡＮからＬＩＮへのデータ転送についてさらに具体的に説明する。
【００２２】
図２３は、例えばＥＣＵ４０１（図２０参照）が、ＣＡＮにおいて１６［ｍｓｅｃ］の周期で受信するデータをＬＩＮに転送する場合の例である。ＬＩＮでは、４［ｍｓｅｃ］周期で起動する定期タスクにて通信スケジュールが制御されている。１つの通信スケジュールは送信フレームの送受信と受信フレームの送受信とで構成される。この例では、１つの通信スケジュール毎に送信フレームが送受信される（ＥＣＵ４０１が送信フレームを送信する）。言い換えると、定期タスク４個分（以下、４タスク分というように記載する）に相当する１６［ｍｓｅｃ］毎に送信フレームが送受信されるようになっている。図２３には、ＬＩＮの通信スケジュールの開始タイミングが１タスク分（４［ｍｓｅｃ］）づつ異なる４つのパターン（ＬＩＮ通信スケジュールパターン（１１）〜（１４））を示している。
【００２３】
図２３に示すように、ＬＩＮ通信スケジュールパターン（１１）〜（１４）のうち、通信スケジュールパターン（１１）において、ＣＡＮにて受信されたデータが最短でＬＩＮに転送されることとなる。
【００２４】
一方、ＬＩＮ通信スケジュールパターン（１２）〜（１４）では、ＣＡＮにて受信されたデータがＬＩＮに転送されるまでには、ＬＩＮ通信スケジュールパターン（１１）と比較して遅れが生じる。
【００２５】
具体的に、ＬＩＮ通信スケジュールパターン（１２）では１タスク分（通信スケジュールの周期の１／４）だけ遅れが生じ、ＬＩＮ通信スケジュールパターン（１３）では２タスク分（通信スケジュールの周期の２／４）だけ遅れが生じ、ＬＩＮ通信スケジュールパターン（１４）では３タスク分（通信スケジュールの周期の３／４）だけ遅れが生じる。
【００２６】
このように、ＣＡＮとＬＩＮとの間でデータ転送する場合、ＣＡＮにおけるデータの受信周期と、ＬＩＮにおける通信スケジュールの周期とが異なれば、ＣＡＮからＬＩＮへのデータの転送に遅れが生じる場合がある。
【００２７】
次に、図２４は、例えばＥＣＵ４０１（図２０参照）が、ＬＩＮにて受信するデータをＣＡＮに転送する場合の態様の例を示す図面である。ＬＩＮでは、４［ｍｓｅｃ］周期で起動する定期タスクにて通信スケジュールが制御されている。１つの通信スケジュールは送信フレームの送受信と受信フレームの送受信とで構成される。この例では、通信スケジュールの１周期毎（４タスク分：１６［ｍｓｅｃ］毎）に受信フレームが送受信されるようになっている。図２４には、ＬＩＮの通信スケジュールの開始タイミングが１タスク分（４［ｍｓｅｃ］）づつ異なる４つのパターン（ＬＩＮ通信スケジュールパターン（１５）〜（１８））を示している。
【００２８】
図２４に示すように、ＬＩＮ通信スケジュールパターン（１５）〜（１８）のうち、通信スケジュールパターン（１８）において、ＬＩＮにて受信されたデータが最短でＣＡＮに転送されることとなる。
【００２９】
一方、ＬＩＮ通信スケジュールパターン（１５）〜（１７）では、ＬＩＮにて受信されたデータがＣＡＮに転送されるまでには、ＬＩＮ通信スケジュールパターン（１８）と比較して遅れが生じる。
【００３０】
具体的に、ＬＩＮ通信スケジュールパターン（１７）では１タスク分（通信スケジュールの周期の１／４）だけ遅れが生じ、ＬＩＮ通信スケジュールパターン（１６）では２タスク分（通信スケジュールの周期の２／４）だけ遅れが生じ、ＬＩＮ通信スケジュールパターン（１５）では３タスク分（通信スケジュールの周期の３／４）だけ遅れが生じる。
【００３１】
このように、ＣＡＮとＬＩＮとの間でデータ転送する場合、ＣＡＮにおけるデータの送信周期と、ＬＩＮにおける通信スケジュールの周期とが異なれば、ＬＩＮからＣＡＮへのデータの転送に遅れが生じる場合がある。
【００３２】
本発明は、こうした問題に鑑みなされたもので、車両における複数のネットワーク間を接続するゲートウェイ装置において、データ転送の効率を向上させることを目的とする。
【課題を解決するための手段】
【００３３】
上記目的を達成するためになされた請求項１に記載の発明は、車両内の複数のネットワークに接続されてそのネットワーク間でのデータ転送を行うゲートウェイ装置であって、少なくとも、マスタ装置によって定期的に起動される通信スケジュールに従って、データの送受信が行われるネットワーク（以下、第１のネットワークと称する）と他のネットワーク（以下、第２のネットワークと称する）との間のデータ転送を行うゲートウェイ装置において、マスタ装置として動作して通信スケジュールを起動するように構成されている。
【００３４】
そして、第１のネットワーク及び第２のネットワークを監視し、転送対象のデータが第１のネットワーク上で送受信される場合の送受信タイミング、及びその転送対象のデータが第２のネットワーク上で送受信される場合の送受信タイミングを検出する検出手段と、検出手段の検出結果に基づき、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期するため、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するための通信スケジュールの起動タイミングを算出する算出手段と、を備え、算出手段により算出された起動タイミングで通信スケジュールを起動するようになっている。
【００３５】
このようなゲートウェイ装置によれば、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期するように第１のネットワークにおける通信スケジュールが起動するため、第１のネットワークで受信されるデータを即座に第２のネットワークに送信できるようになる。また、第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するように第１のネットワークにおける通信スケジュールが起動するため、第２のネットワークで受信されるデータを即座に第１のネットワークに送信できるようになる。つまり、第１のネットワークと第２のネットワークとの間において、転送対象のデータをより短時間で転送できるようになる。
【００３６】
また、検出手段を備えていることによって、所望のデータについて送受信タイミングを検出することができる。このため、状況に応じて送受信タイミングの検出対象（言い換えると、同期をとる対象）のデータを変更しても良く、その時々に応じて転送の最適化を図ることが可能である。
【００３７】
特に、転送対象のデータが複数あるような場合には、請求項２のように構成すると良い。
【００３８】
請求項２のゲートウェイ装置は、請求項１のゲートウェイ装置において、転送対象のデータは複数種類あり、その複数種類のデータには重要度を表す情報が含まれ、検出手段は、複数種類のデータのうち重要度が最も高いデータについて、第１のネットワーク上での送受信タイミング、及び第２のネットワーク上での送受信タイミングを検出するようになっている。
【００３９】
このようなゲートウェイ装置によれば、重要度の最も高いデータについて、第１のネットワーク上での送受信タイミング、及び第２のネットワーク上での送受信タイミングが検出されるため、その重要度の最も高いデータについて、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期する、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するようになる。従って、その重要度の最も高いデータがより短時間に転送されるようになる。
【００４０】
また、転送対象のデータが複数ある場合においては、請求項３のように構成しても良い。
【００４１】
請求項３のゲートウェイ装置は、請求項１のゲートウェイ装置において、転送対象のデータは複数種類あり、算出手段は、転送対象のデータの第２のネットワーク上における送受信タイミングの度数分布を算出し、その度数分布に基づき、第１のネットワーク上での送信のタイミングと第２のネットワーク上での受信のピークとが同期するため、或いは第１のネットワーク上での受信のタイミングと第２のネットワーク上での送信のピークとが同期するための通信スケジュールの起動タイミングを算出するようになっている。
【００４２】
この場合、第１のネットワーク上の送信のタイミングと、第２のネットワーク上にて受信の発生が相対的に多いタイミングとが同期する。或いは、第１のネットワークの受信のタイミングと、第２のネットワーク上にて送信の発生が相対的に多いタイミングとが同期する。このような構成によれば、複数のデータを対象として、全体的に転送時間を短くし得る。
【００４３】
次に、請求項４のゲートウェイ装置は、請求項１〜３のゲートウェイ装置において、通信スケジュールの起動タイミングを所定量づつ徐々に変更して算出手段により算出された起動タイミングに一致させることを特徴としている。
【００４４】
通信スケジュールの起動タイミングを、算出手段により算出された起動タイミングに変更する場合、その変更量が大きいと、通信に影響が出ることも懸念される。例えば、変更の結果起動タイミングが大幅に遅れた場合、受信側において通信途絶と判断されてしまうような可能性もある。
【００４５】
例えば、本来、１回目の通信スケジュールが時刻Ｔ１で起動して、その後は通信スケジュールが１０［ｍｓｅｃ］毎に起動する例があるとする。つまり、通信スケジュールの起動タイミングは、Ｔ１、Ｔ１＋１０、Ｔ１＋２０、Ｔ１＋３０、Ｔ１＋４０、Ｔ１＋５０・・・である。
【００４６】
これを、Ｔ１にて通信スケジュールを起動した後に、Ｔ１＋１６、Ｔ１＋２６、Ｔ１＋３６、Ｔ１＋４６、Ｔ１＋５６・・・というように通信スケジュールの起動タイミングを変更したいとする。そうすると、Ｔ１で起動した後に１６［ｍｓｅｃ］待って次の通信スケジュールを起動すれば良いわけであるが、本来のＴ１＋１０から見て６［ｍｓｅｃ］も遅れ、その間はデータの送受信がなされないため、不都合が生じる可能性もある。
【００４７】
この点、本請求項４の発明では、所定量ずつ徐々に変更して目標とする起動タイミングに近づける。例えば、上記のように、Ｔ１＋１６、Ｔ１＋２６、Ｔ１＋３６、Ｔ１＋４６、Ｔ１＋５６・・・という起動タイミングに変更したい場合、当初は２［ｍｓｅｃ］づつずらし、Ｔ１、Ｔ１＋１２、Ｔ１＋２４、Ｔ１＋３６・・・とし、その後は１０［ｍｓｅｃ］毎に起動してＴ１＋４６、Ｔ＋５６・・・とするような例が考えられる。これによれば、起動タイミングを徐々にずらしつつ、最終的には目標とする起動タイミングに一致させることができる。このように、目標とする起動タイミングに一致させるまでの変更量を小さくできるため、例えば通信途絶と誤判断されてしまうような事態を回避し得る。
【００４８】
ところで、データの転送がより緊急を要する場合、請求項５のように構成しても良い。
【００４９】
請求項５のゲートウェイ装置は、請求項１〜３のゲートウェイ装置において、転送対象のデータには緊急度を表す情報が含まれ、緊急度を表す情報に基づき緊急を要するか否かを判断し、緊急を要すると判断すると、現在動作中の通信スケジュールを中止し、新たな通信スケジュールを起動するようになっている。
【００５０】
これによれば、現在動作中の通信スケジュールが終了するまで待つという必要がなくなり、即座に所望のタイミングで新たな通信スケジュールを開始できる。従って、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミング、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミング、とを即座に同期させることも可能である。
【００５１】
次に、請求項６のゲートウェイ装置は、請求項１〜５のゲートウェイ装置において、通信スケジュールの起動タイミングを変更した後、予め定められた時間が経過するまでは再度の変更を行わないようになっている。
【００５２】
通信スケジュールの起動タイミングの変更を頻繁に行うと、通信スケジュールの起動タイミングが一定でなくなったりして、かえって転送効率が悪くなるおそれがある。そこで、請求項６のように構成すれば、起動タイミングの頻繁な変更を抑制することができ、かえって通信効率が悪くなるというような問題が生じることを防止することができる。
【００５３】
次に、請求項７のゲートウェイ装置は、請求項１のゲートウェイ装置において、所定の転送対象のデータに代え、その転送対象のデータと同じタイミングでダミーデータの送受信を行うダミーデータ送受信手段を備え、検出手段は、ダミーデータが第１のネットワーク上で送受信される場合の送受信タイミング、及びそのダミーデータが第２のネットワーク上で送受信される場合の送受信タイミングを検出し、算出手段は、ダミーデータについて、第１のネットワーク上での送信タイミングと第２のネットワーク上での受信タイミングとが同期するため、或いは第１のネットワーク上での受信タイミングと第２のネットワーク上での送信タイミングとが同期するための通信スケジュールの起動タイミングを算出するようになっている。
【００５４】
このような構成によれば、例えばゲートウェイ装置がデータ転送や制御対象の制御を行わない時間（例えば、起動直後の初期化処理中など）に、ダミーデータを用いて通信スケジュールの起動タイミングを予め調整することができる。
【００５５】
予め調整しておくことで、例えばデータ転送を頻繁に行う必要があるときや制御対象の制御中などに通信スケジュールの起動タイミングを変更しなくても良くなる。
【００５６】
次に、請求項８のゲートウェイ装置は、請求項１〜７に記載のゲートウェイ装置において、通信スケジュールの起動タイミングを変更することを表す情報を第１のネットワーク及び第２のネットワークの両方又は一方に送出するようになっている。
【００５７】
これによれば、第１のネットワーク上、第２のネットワーク上における通信装置は、データの送受信のタイミングが変更されることを認識できるようになる。
【００５８】
例えば、送受信のタイミングが変更された場合、通信装置がその変更を認識できなければ、場合によっては通信途絶と判断する可能性もある。一方、通信装置が送受信のタイミングの変更を認識できれば、それに伴いその通信装置において通信途絶の判定処理を無効にするようなことも可能であり、通信装置において不要に通信途絶と判断されるような事態を回避することができる。
【図面の簡単な説明】
【００５９】
【図１】本実施形態の車両ネットワークを示す図面である。
【図２】本実施形態のＥＣＵ１０１（ゲートウェイ）の構成を示す図面である。
【図３】前提条件判定処理の流れを表すフローチャートである。
【図４】前提条件を説明するための図である（その１）。
【図５】前提条件を説明するための図である（その２）。
【図６】前提条件を説明するための図である（その３）。
【図７】前提条件を説明するための図である（その４）。
【図８】前提条件を説明するための図である（その５）。
【図９】前提条件を説明するための図である（その６）。
【図１０】ＥＣＵ１０１の通信同期装置２０２において実行される処理を表すフローチャートである。
【図１１】ＥＣＵ１０１のＬＩＮ通信スケジューラ２０６において実行される処理を表すフローチャートである。
【図１２】変形例１を説明するための図面である（ＣＡＮからＬＩＮへの転送）。
【図１３】変形例１を説明するための図面である（ＬＩＮからＣＡＮへの転送）。
【図１４】変形例２を説明するための図面である。
【図１５】変形例３を説明するための図面である。
【図１６】変形例４を説明するための図面である。
【図１７】変形例５を説明するための図面である（タイムチャート）。
【図１８】変形例５を説明するための図面である（グラフ）。
【図１９】従来の車両ネットワークの一例示す図面である。
【図２０】従来の車両ネットワークの一例示す図面である（多重通信）。
【図２１】ＬＩＮにおけるフレームの構成を説明する図面である。
【図２２】ＣＡＮからＬＩＮへのデータ転送の態様の一例を表す図面である。
【図２３】ＣＡＮからＬＩＮへのデータ転送の態様のパターンを表す図面である。
【図２４】ＬＩＮからＣＡＮへのデータ転送の態様のパターンを表す図面である。
【発明を実施するための形態】
【００６０】
以下、本発明の実施形態を図面に基づき説明する。
［第１実施形態］
図１は、本実施形態の車両ネットワークを示す図面である。尚、図１に示す車両ネットワーク１００は、図２０に示す車両ネットワーク４００と比較して符号のみが異なり、構成はその車両ネットワーク４００と同じである。このため、ここでは車両ネットワーク１００の構成の説明は省略する。
【００６１】
図２は、図１におけるＥＣＵ１０１の具体的構成を表す構成図である。
【００６２】
図２に示すように、本実施形態のＥＣＵ１０１は、通信同期装置２０２と、ＣＡＮ通信ドライバ２０３と、データベース２０４と、ＬＩＮ通信ドライバ２０５と、ＬＩＮ通信スケジューラ２０６と、を備えている。
【００６３】
ＣＡＮ通信ドライバ２０３は、ＣＡＮ通信線２０７からのデータを受信し、その受信したデータをデータベース２０４に格納するとともに、データの受信完了通知を通信同期装置２０２に送る。
【００６４】
通信同期装置２０２は、ＣＡＮ通信ドライバ２０３から受信完了通知を受けると、通信スケジュールの調整指示をＬＩＮ通信スケジューラ２０６に送る。
【００６５】
ＬＩＮ通信スケジューラ２０６は、通信同期装置２０２からの調整指示に基づき、通信スケジュール（通信の開始時間）を調整したうえで、ＬＩＮ通信ドライバ２０５に通信指示を送る。
【００６６】
ＬＩＮ通信ドライバ２０５は、ＬＩＮ通信スケジューラ２０６から通信指示を受けると、その通信指示に基づき、データベース２０４から該当データを取得し、その取得したデータをＬＩＮ通信線２０８に送出する。そして、データの送出が完了すると、ＬＩＮ通信スケジューラ２０６が送信完了通知を通信同期装置２０２に送る。
【００６７】
このようにして、ＣＡＮからＬＩＮにデータが転送される。
【００６８】
また、ＬＩＮ通信ドライバ２０５は、ＬＩＮ通信線２０８からのデータを受信し、その受信したデータをデータベース２０４に格納するとともに、データの受信完了通知をＬＩＮ通信スケジューラ２０６に送る。
【００６９】
ＬＩＮ通信スケジューラ２０６は、通信同期装置２０２に受信完了通知を送る。また、通信同期装置２０２は、ＬＩＮ通信スケジューラ２０６から受信完了通知を受けた旨をＣＡＮ通信ドライバ２０３に送る。
【００７０】
ＣＡＮ通信ドライバ２０３は、通信同期装置２０２からのその通知に基づき、データベース２０４から該当データを取得し、その取得したデータをＣＡＮ通信線２０７に送出する。ここで、ＣＡＮ通信ドライバ２０３は、送出対象のデータの送信周期或いは送信タイミングが予め定められている場合は、その送信周期或いは送信タイミングに従ってデータを送出する。この際に、ＣＡＮ通信線２０７が空いていれば、ＣＡＮ通信ドライバ２０３からＣＡＮ通信線２０７上にデータが送出される。一方、他のデータの送受信によりＣＡＮ通信線２０７が空いていなければ、再度送出の処理が行われる。そして、ＣＡＮ通信ドライバ２０３は、データの送出が完了すると、送信完了通知を通信同期装置２０２に送る。
【００７１】
このようにして、ＬＩＮからＣＡＮにデータが転送される。
【００７２】
このような本実施形態では、ＥＣＵ１０１の通信同期装置２０２が図１０の処理を実行し、ＥＣＵ１０１のＬＩＮ通信スケジューラ２０６が図１１に示す処理を実行して、ＣＡＮにおける送受信タイミングとＬＩＮにおける送受信タイミング（通信スケジュール）との同期をとるようになっている。
【００７３】
ここで、本実施形態では、予め、転送対象のデータのＣＡＮにおける送受信周期（以下、ＣＡＮ送受信周期、Ｔｃとも記載する）と、ＬＩＮの通信スケジュールの周期（以下、ＬＩＮ通信スケジュール周期、Ｔｌとも記載する）とを解析し、周期についての前提条件が成立するか否かを判定する。
【００７４】
この周期についての前提条件が成立するか否かの判定に係る処理の流れを表すフローチャートを、図３に示す。図３に示す前提条件判定処理は、例えば車両ネットワーク１００を仮想的に構築して動作をシミュレーションする図示しないコンピュータにおいて実行される。そして、そのコンピュータにおける処理結果を使用者が見て、周期についての前提条件が成立するか否かを確認する。尚、図３に示す前提条件判定処理は車両ネットワーク１００のＥＣＵ１０１において実行されるようにしても良いが、前者のように他のコンピュータにおいて実行されるようにすることで、ＥＣＵ１０１の処理負荷を抑えることができる。
【００７５】
図３の前提条件判定処理では、図示しないコンピュータのＣＰＵは、まずＳ１０において、ＣＡＮ送受信周期と、ＬＩＮ通信スケジュール周期とが等しいか否かを判定し、等しいと判定すると（Ｓ１０：ＹＥＳ）、有効である（周期についての前提条件が成立する）と判断して当該処理を終了する。
【００７６】
一方、Ｓ１０においてＣＡＮ送受信周期とＬＩＮ通信スケジュール周期とが等しくないと判定すると（Ｓ１０：ＮＯ）、Ｓ２０に移行する。尚、Ｓ２０の処理の内容については、図４〜９の説明の際にも補足する。
【００７７】
Ｓ２０では、ＣＡＮ送受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間において、ＣＡＮの送受信タイミングとＬＩＮの通信スケジュールの開始タイミングとのずれのパターンが、とり得る全パターン現れるか否かを判定し、全パターンは出現しないと判定すると（Ｓ２０：ＹＥＳ）、有効である（周期に関する前提条件が成立する）と判断して当該処理を終了する。
【００７８】
一方、Ｓ２０で全パターン出現すると判定すると（Ｓ２０：ＮＯ）、無効である（周期に関する前提条件が成立しない）と判断して当該処理を終了する。
【００７９】
Ｓ２０でＹＥＳと肯定判定される場合（周期についての前提条件が成立すると判定される場合）と、ＮＯと否定判定される場合（周期についての前提条件が成立しないと判定される場合）とについて、図４〜９を用いて具体的に説明する。
【００８０】
図４〜６は、ＣＡＮにおいて受信されたデータをＬＩＮに転送する場合のそのＣＡＮとＬＩＮとの間の周期のずれのパターンの態様を示すものである。
【００８１】
図７〜９は、ＬＩＮにおいて受信されたデータをＣＡＮに転送する場合のそのＬＩＮとＣＡＮとの間の周期のずれのパターンの態様を示すものである。
【００８２】
ここで、ＬＩＮにおいては、所定の周期で定期タスクが起動し、その定期タスクに従って通信スケジュールが開始される。図４〜９の上段には定期タスクを示しており、１周期毎に「１」から続く連続番号を付している。以下、便宜的に、ＣＡＮにおける送受信周期も定期タスクを基準にして表す。
〈図４の例：ＣＡＮ→ＬＩＮ〉
まず、図４は、ＣＡＮにおける受信周期（以下、ＣＡＮ受信周期とも記載する）が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク６個分の場合である。そして、ＣＡＮにけるデータの受信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０、定期タスク２４・・・のタイミングに相当しているものとする。尚、その受信されるデータを順に、ｄａｔａ（１）、ｄａｔａ（２）、ｄａｔａ（３）、ｄａｔａ（４）、ｄａｔａ（５）、ｄａｔａ（６）・・・とする。また、ｄａｔａ（１）の前に受信されるデータはｄａｔａ（０）とし、さらにその前に受信されるデータはｄａｔａ（−１）とする。ＣＡＮにおいて受信されるそのようなｄａｔａ（−１）〜（６）は、ＬＩＮの通信スケジュールに従ってＬＩＮに転送される。
【００８３】
ＣＡＮにおける受信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図４の例では６通り考えられる（ｏｆｆｓｅｔ＝０〜５）。
【００８４】
ｏｆｆｓｅｔ＝０〜５の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，７，１３，１９・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，８，１４，２０・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）、定期タスク３，９，１５，２１・・・で開始される場合（ｏｆｆｓｅｔ＝２の場合）、定期タスク４，１０，１６，２２・・・で開始される場合（ｏｆｆｓｅｔ＝３の場合）、定期タスク５，１１，１７，２３・・・で開始される場合（ｏｆｆｓｅｔ＝４の場合）、定期タスク６，１２，１８，２４・・・で開始される場合（ｏｆｆｓｅｔ＝５の場合）を表す。
【００８５】
ここで、ｏｆｆｓｅｔ＝０〜５のそれぞれのパターンについて、ＣＡＮにてデータが受信されるタイミングが、ＬＩＮにおける通信スケジュールの開始タイミングからみて幾つ目の定期タスクに相当するかを検討する。尚、この幾つ目であるかを表す数字を図中に併記している。図５〜９においても同様に併記している。また、以下、この幾つ目であるかを表す数字をＮｃｌと定義する。
【００８６】
ｏｆｆｓｅｔ＝０の例では、まず、最初の通信スケジュールの開始タイミング（定期タスク１）から数えて、４個目の定期タスク（以下、４タスク目というように記載する）でＣＡＮにてデータが受信されている。
【００８７】
続いて、次の通信スケジュールの開始タイミング（定期タスク７）から数えて、２タスク目（Ｎｃｌ＝２）にＣＡＮにてデータが受信されている。さらに、同じ通信スケジュールの開始タイミング（定期タスク７）から数えて、６タスク目（Ｎｃｌ＝６）にＣＡＮにてデータが受信されている。
【００８８】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける受信タイミングが何タスク目であるか（つまりＮｃｌの値）を、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり定期タスク１〜１２の期間）について抽出すると、ｏｆｆｓｅｔ＝０の例では、Ｎｃｌは（２，４，６）の値をとり得る。
【００８９】
同じようにして、ｏｆｆｓｅｔ＝１の例について抽出した場合、Ｎｃｌは（１，３，５）の値をとり得る。
【００９０】
そして、ｏｆｆｓｅｔ＝２，４の例の場合はｏｆｆｓｅｔ＝０と同じくＮｃｌは（２，４，６）の値をとり、ｏｆｆｓｅｔ＝３，５の例の場合はｏｆｆｓｅｔ＝１と同じくＮｃｌは（１，３，５）の値をとり得る。
【００９１】
このように、図４の例では、Ｎｃｌが（１，３，５，）、（２，４，６）の何れかをとり、（１，２，３，４，５，６）という全ての値（パターン）をとる例はないから、図３の前提条件判定処理におけるＳ２０では、全パターン出現しないというように肯定判定され（Ｓ２０：ＹＥＳ）、有効である（周期についての前提条件が成立する）と判断される。言い換えると、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られると判断される。
【００９２】
実効性の有無について検討するために、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜１２の期間）について、ＣＡＮにてデータを受信してから、そのデータをＬＩＮに転送するまで（ＬＩＮの通信スケジュールが開始するまで）に要する時間の合計（以下、合計転送時間と記載する）を検討する。
【００９３】
ｏｆｆｓｅｔ＝０の例では、定期タスク１〜１２の期間において、ｄａｔａ（０），（１）がＬＩＮに転送されている。ｄａｔａ（０）については、ＣＡＮにおける受信タイミング（図示しないが、定期タスク１の直前）とＬＩＮへの転送タイミング（通信スケジュールの開始タイミングであり、定期タスク１）とは同期しており、転送の遅れは発生していない。次に、ｄａｔａ（１）については、定期タスク４中に相当するタイミングでＣＡＮにて受信され、その後定期タスク７にてＬＩＮに転送開始（ＬＩＮの通信スケジュールが開始）されており、転送開始までには２タスク分の遅れがある。以上より、合計転送時間は２タスク分である。
【００９４】
同様にして、ｏｆｆｓｅｔ＝１〜５の例の場合について合計転送時間を検討すると、ｏｆｆｓｅｔ＝１の例では４タスク分となり、ｏｆｆｓｅｔ＝２の例では２タスク分となり、ｏｆｆｓｅｔ＝３の例では４タスク分となり、ｏｆｆｓｅｔ＝４の例では２タスク分となり、ｏｆｆｓｅｔ＝５の例では４タスク分となる。
【００９５】
このような図４の例では、ｏｆｆｓｅｔ＝１，３，５の場合、合計転送時間が２タスク分となるようにＬＩＮにおける通信スケジュールの開始タイミングを調整する（ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとる）ことができるはずである。つまり、転送に要する時間を短くする（最短にする）ことができ、同期をとることの実効性が得られるということになる。
〈図５の例：ＣＡＮ→ＬＩＮ〉
次に、図５は、ＣＡＮ受信周期が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク５個分の場合である。そして、ＣＡＮにけるデータの受信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０・・・のタイミングに相当しているものとする。
【００９６】
ＣＡＮにおける受信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図５の例では５通り考えられる（ｏｆｆｓｅｔ＝０〜４）。
【００９７】
ｏｆｆｓｅｔ＝０〜４の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，６，１１，１６・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，７，１２，１７・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）、定期タスク３，８，１３，１８・・・で開始される場合（ｏｆｆｓｅｔ＝２の場合）、定期タスク４，９，１４，１９・・・で開始される場合（ｏｆｆｓｅｔ＝３）、定期タスク５，１０，１５，２０・・・で開始される場合（ｏｆｆｓｅｔ＝４）を表す。
【００９８】
ここで、ｏｆｆｓｅｔ＝０〜４のそれぞれのパターンについて、ＣＡＮにてデータが受信されるタイミングが、ＬＩＮにおける通信スケジュールの開始タイミングからみて幾つ目の定期タスクに相当するかを検討する。つまり、Ｎｃｌの値を検討する。
【００９９】
ｏｆｆｓｅｔ＝０の例では、まず、最初の通信スケジュールの開始タイミング（定期タスク１）から数えて、４タスク目（Ｎｃｌ＝４）にＣＡＮにてデータが受信されている。また、次の通信スケジュールの開始タイミング（定期タスク６）から数えて、３タスク目（Ｎｃｌ＝３）にＣＡＮにてデータが受信されている。さらに、次の通信スケジュールの開始タイミング（定期タスク１１）から数えて、２タスク目（Ｎｃｌ＝２）にＣＡＮにてデータが受信されている。さらに次の通信スケジュールの開始タイミング（定期タスク１６）から数えて、１タスク目（Ｎｃｌ＝１）にＣＡＮにてデータが受信されている。そして、同じ通信スケジュールの開始タイミング（定期タスク１６）から数えて、５タスク目（Ｎｃｌ＝５）にＣＡＮにてデータが受信されている。
【０１００】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける受信タイミングが何タスク目であるか（つまりＮｃｌの値）を、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり定期タスク１〜２０の期間）について抽出すると、ｏｆｆｓｅｔ＝０の例では、Ｎｃｌは（１，２，３，４，５，）の値をとり得る。
【０１０１】
ｏｆｆｓｅｔ＝１〜４の例の場合も同様にＮｃｌは（１，２，３，４，５，）の値をとり得る。
【０１０２】
このように、図５の例では、Ｎｃｌが（１，２，３，４，５，）という全ての値（パターン）をとるから、図３の前提条件判定処理におけるＳ２０では、全パターン出現するというように否定判定され（Ｓ２０：ＮＯ）、無効である（周期についての前提条件が成立しない）と判断される。言い換えると、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られないと判断される。
【０１０３】
実効性の有無について検討するために、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜２０の期間）について、ＣＡＮにてデータを受信してから、そのデータをＬＩＮに転送するまで（ＬＩＮの通信スケジュールが開始するまで）に要する時間の合計（合計転送時間）を検討する。
【０１０４】
ｏｆｆｓｅｔ＝０の例では、定期タスク１〜２０の期間において、ｄａｔａ（０）〜（３）がＬＩＮに転送されている。ｄａｔａ（０）については、ＣＡＮにおける受信タイミング（図示しないが、定期タスク１の直前）とＬＩＮへの転送タイミング（通信スケジュールの開始タイミングであり、定期タスク１）とは同期しており、転送の遅れは発生していない。次に、ｄａｔａ（１）については、定期タスク４中に相当するタイミングでＣＡＮにて受信され、その後定期タスク６で転送開始（ＬＩＮの通信スケジュールが開始）されており、転送開始までには１タスク分（定期タスク５の分）の遅れがある。ｄａｔａ（２）については、定期タスク８に相当するタイミングでＣＡＮにて受信され、その後定期タスク１１で転送開始（ＬＩＮの通信スケジュールが開始）されており、転送開始までには２タスク分（定期タスク９，１０の分）の遅れがある。ｄａｔａ（３）については、定期タスク１２に相当するタイミングでＣＡＮにて受信され、その後定期タスク１６で転送開始（ＬＩＮの通信スケジュールが開始）されており、転送開始までには３タスク分（定期タスク１３，１４，１５の分）の遅れがある。以上より、１タスク分、２タスク分、及び３タスク分を合計して合計転送時間は６タスク分となる。
【０１０５】
同様にして、ｏｆｆｓｅｔ＝１〜４の例の場合について合計転送時間を検討すると、全て６タスク分となる。つまり、これ以上は合計転送時間を小さくすることはできないということになる。つまり、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性は得られないということになる。
〈図６の例：ＣＡＮ→ＬＩＮ〉
次に、図６は、ＣＡＮ受信周期が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク２個分の場合である。そして、ＣＡＮにけるデータの受信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０・・・のタイミングに相当しているものとする。
【０１０６】
ＣＡＮにおける受信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図６の例では２通り考えられる（ｏｆｆｓｅｔ＝０，１）。
【０１０７】
ｏｆｆｓｅｔ＝０，１の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，３，５，７，９，・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，４，６，８，１０・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）を表す。
【０１０８】
ここで、ｏｆｆｓｅｔ＝０，１のそれぞれのパターンにおいて、通信スケジュールの開始タイミングからみて、幾つ目の定期タスクにてＣＡＮにおいてデータが受信されるかを検討する。つまり、Ｎｃｌの値を検討する。
【０１０９】
ｏｆｆｓｅｔ＝０の例では、通信スケジュールの開始タイミング（定期タスク３）から数えて、２タスク目（Ｎｃｌ＝２）にＣＡＮにてデータが受信されている。また、通信スケジュールの開始タイミング（定期タスク７）から数えて、２タスク目（Ｎｃｌ＝２）にＣＡＮにてデータが受信されている。以降も同様に、直前の通信スケジュールの開始タイミングから数えて、２タスク目（Ｎｃｌ＝２）にＣＡＮにてデータが受信されている。
【０１１０】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける受信タイミングが何タスク目であるか（つまりＮｃｌの値）を、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜４の期間）について抽出すると、ｏｆｆｓｅｔ＝０の例では、Ｎｃｌは（２）の値をとり得る。
【０１１１】
同じようにして、ｏｆｆｓｅｔ＝１の例について抽出した場合、Ｎｃｌは（１）の値をとり得る。
【０１１２】
このように、図６の例では、Ｎｃｌが（１）、（２）の何れかをとり、（１，２）という全ての値（パターン）をとる例はないから、図３の前提条件判定処理におけるＳ２０では、全パターン出現しないというように肯定判定され（Ｓ２０：ＹＥＳ）、有効である（周期についての前提条件が成立する）と判断される。言い換えると、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られると判断される。
【０１１３】
実効性の有無について検討するために、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜４の期間）について、ＣＡＮにてデータを受信してから、そのデータをＬＩＮに転送するまで（ＬＩＮの通信スケジュールが開始するまで）に要する時間の合計（合計転送時間）を検討する。
【０１１４】
ｏｆｆｓｅｔ＝０の例では、定期タスク１〜４の期間において、ｄａｔａ（０）がＬＩＮに転送されている。ｄａｔａ（０）は、ＣＡＮにおいて受信されると（図示しないが、定期タスク１の直前に受信される）、その後、定期タスク１，３で開始される通信スケジュールですぐにＬＩＮに転送されるようになっており、転送の遅れは発生していない。以上より、合計転送時間は０タスク分である。
【０１１５】
ｏｆｆｓｅｔ＝１の例では、定期タスク１〜４の期間において、ｄａｔａ（０）がＬＩＮに転送されている。ｄａｔａ（０）は、ＣＡＮにおいて受信されると、その後、定期タスク２，４で開始される通信スケジュールでＬＩＮに転送されるようになっており、転送開始までには１タスク分（定期タスク１の分）の遅れが発生している。以上より、合計転送時間は１タスク分である。
【０１１６】
このような図６の例では、ｏｆｆｓｅｔ＝１の例の場合、合計転送時間が０タスク分となるようにＬＩＮにおける通信スケジュールの開始タイミングを調整する（ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとる）ことができるはずである。つまり、転送に要する時間を短くする（最短にする）ことができ、同期をとることの実効性が得られるということになる。
【０１１７】
図７〜９は、前述のようにＬＩＮにおいて受信されたデータをＣＡＮに転送する場合のそのＬＩＮとＣＡＮとの間の周期のずれのパターンの態様を示すものである。
〈図７の例：ＬＩＮ→ＣＡＮ〉
まず、図７は、ＣＡＮにおける送信周期（以下、ＣＡＮ送信周期とも記載する）が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク６個分の場合である。そして、ＣＡＮにおけるデータの送信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０、定期タスク２４・・・のタイミングに相当しているものとする。
【０１１８】
ＣＡＮにおける送信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図７の例では６通り考えられる（ｏｆｆｓｅｔ＝０〜５）。
【０１１９】
ｏｆｆｓｅｔ＝０〜５の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，７，１３，１９・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，８，１４，２０・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）、定期タスク３，９，１５，２１・・・で開始される場合（ｏｆｆｓｅｔ＝２の場合）、定期タスク４，１０，１６，２２・・・で開始される場合（ｏｆｆｓｅｔ＝３の場合）、定期タスク５，１１，１７，２３・・・で開始される場合（ｏｆｆｓｅｔ＝４の場合）、定期タスク６，１２，１８，２４・・・で開始される場合（ｏｆｆｓｅｔ＝５の場合）を表す。
【０１２０】
ここで、ｏｆｆｓｅｔ＝０〜５のそれぞれのパターンにおいて、ＣＡＮにてデータが送信されるタイミングが、ＬＩＮにおける通信スケジュールの開始タイミングからみて幾つ目の定期タスクに相当するかを検討する。尚、以下、この幾つ目であるかを表す数字をＮｌｃと定義する。
【０１２１】
ｏｆｆｓｅｔ＝０の例では、まず、最初の通信スケジュールの開始タイミング（定期タスク１）から数えて、４タスク目（Ｎｌｃ＝４）にＣＡＮにてデータが送信されている。
【０１２２】
続いて、次の通信スケジュールの開始タイミング（定期タスク７）から数えて、２タスク目（Ｎｌｃ＝２）にＣＡＮにてデータが送信されている。さらに、同じ通信スケジュールの開始タイミング（定期タスク７）から数えて、６タスク目（Ｎｌｃ＝６）にＣＡＮにてデータが送信されている。
【０１２３】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける送信タイミングが何タスク目であるか（つまりＮｌｃの値）を、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり定期タスク１〜１２の期間）について抽出すると、Ｎｌｃは（２，４，６，）の値をとり得る。
【０１２４】
同じようにして、ｏｆｆｓｅｔ＝１の例について抽出した場合、Ｎｌｃは（１，３，５）の値をとり得る。
【０１２５】
そして、ｏｆｆｓｅｔ＝２，４の例の場合はｏｆｆｓｅｔ＝０と同じくＮｌｃは（２，４，６）の値をとり、ｏｆｆｓｅｔ＝３，５の例の場合はｏｆｆｓｅｔ＝１と同じくＮｌｃは（１，３，５）の値をとり得る。
【０１２６】
このように、図７の例では、Ｎｌｃが（１，３，５，）、（２，４，６）の何れかをとり、（１，２，３，４，５，６）という全ての値（パターン）をとる例はないから、図３の前提条件判定処理におけるＳ２０では、全パターン出現しないというように肯定判定され（Ｓ２０：ＹＥＳ）、有効である（周期についての前提条件が成立する）と判断される。言い換えると、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られると判断される。
【０１２７】
実効性の有無について検討するために、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜１２の期間）について、ＬＩＮの通信スケジュールの開始点を起点として、ＣＡＮ送信（転送）が発生するまでの時間の合計（合計転送時間）を検討する。
【０１２８】
ｏｆｆｓｅｔ＝０の例では、定期タスク１でＬＩＮの通信スケジュールが開始し、定期タスク４に相当するタイミングでＣＡＮ送信が発生し、その間は３タスク分（定期タスク１，２，３の分）の時間がある。また、定期タスク７で通信スケジュールが開始し、定期タスク８，１２に相当するそれぞれのタイミングでＣＡＮ送信が発生し、その間はそれぞれ、１タスク分（定期タスク７の分）、５タスク分（定期タスク７，８，９，１０，１１の分）の時間がある。以上より、３タスク分、１タスク分、及び５タスク分を合計して合計転送時間は９タスク分である。
【０１２９】
同様にして、ｏｆｆｓｅｔ＝１〜５の例の場合について合計転送時間を検討すると、ｏｆｆｓｅｔ＝１の例では６タスク分となり、ｏｆｆｓｅｔ＝２の例では９タスク分となり、ｏｆｆｓｅｔ＝３の例では６タスク分となり、ｏｆｆｓｅｔ＝４の例では９タスク分となり、ｏｆｆｓｅｔ＝５の例では６タスク分となる。
【０１３０】
このような図７の例では、ｏｆｆｓｅｔ＝０，２，４の例の場合、合計転送時間が６タスク分となるようにＬＩＮにおける通信スケジュールの開始タイミングを調整する（ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との同期をとる）ことができるはずである。つまり、転送に要する時間を短くする（最短にする）ことができ、同期をとることの実効性が得られるということになる。
〈図８の例：ＬＩＮ→ＣＡＮ〉
次に、図８は、ＣＡＮ送信周期が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク５個分の場合である。例えば、そして、ＣＡＮにけるデータの送信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０・・・のタイミングに相当しているものとする。
【０１３１】
ＣＡＮにおける送信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図８の例では５通り考えられる（ｏｆｆｓｅｔ＝０〜４）。
【０１３２】
ｏｆｆｓｅｔ＝０〜４の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，６，１１，１６・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，７，１２，１７・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）、定期タスク３，８，１３，１８・・・で開始される場合（ｏｆｆｓｅｔ＝２の場合）、定期タスク４，９，１４，１９・・・で開始される場合（ｏｆｆｓｅｔ＝３）、定期タスク５，１０，１５，２０・・・で開始される場合（ｏｆｆｓｅｔ＝４）を表す。
【０１３３】
ここで、ｏｆｆｓｅｔ＝０〜４のそれぞれのパターンにおいて、ＣＡＮにてデータが送信されるタイミングが、ＬＩＮにおける通信スケジュールの開始タイミングからみて幾つ目の定期タスクに相当するかを検討する。つまり、Ｎｌｃを検討する。
【０１３４】
ｏｆｆｓｅｔ＝０の例では、まず、最初の通信スケジュールの開始タイミング（定期タスク１）から数えて、４タスク目（Ｎｌｃ＝４）にＣＡＮにてデータが送信されている。また、次の通信スケジュールの開始タイミング（定期タスク６）から数えて、３タスク目（Ｎｌｃ＝３）にＣＡＮにてデータが送信されている。さらに、次の通信スケジュールの開始タイミング（定期タスク１１）から数えて、２タスク目（Ｎｌｃ＝２）にＣＡＮにてデータが送信されている。さらに次の通信スケジュールの開始タイミング（定期タスク１６）から数えて、１タスク目（Ｎｌｃ＝１）にＣＡＮにてデータが送信されている。そして、同じ通信スケジュールの開始タイミング（定期タスク１６）から数えて、５タスク目（Ｎｌｃ＝５）にＣＡＮにてデータが送信されている。
【０１３５】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける送信タイミングが何タスク目であるか（つまりＮｌｃの値）を、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり定期タスク１〜２０の期間）について抽出すると、Ｎｌｃは（１，２，３，４，５）の値をとり得る。
【０１３６】
ｏｆｆｓｅｔ＝１〜４の例の場合も同様にＮｌｃは（１，２，３，４，５）の値をとり得る。
【０１３７】
このように、図８の例では、Ｎｌｃが（１，２，３，４，５，）という全ての値（パターン）をとるから、図３の前提条件判定処理におけるＳ２０では、全パターン出現するというように否定判定され（Ｓ２０：ＮＯ）、無効である（周期についての前提条件が成立しない）と判断される。言い換えると、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られないと判断される。
【０１３８】
実効性の有無について検討するために、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜２０の期間）について、ＬＩＮの通信スケジュールの開始点を起点として、ＣＡＮ送信（転送）が発生するまでの時間の合計（合計転送時間）を検討する。
【０１３９】
ｏｆｆｓｅｔ＝０の例では、定期タスク１でＬＩＮの通信スケジュールが起動し、定期タスク４に相当するタイミングでＣＡＮ送信が発生し、その間は３タスク分（定期タスク１，２，３の分）の時間がある。また、定期タスク６で通信スケジュールが起動し、定期タスク８に相当するタイミングでＣＡＮ送信が発生し、その間は２タスク分（定期タスク６，７の分）の時間がある。また、定期タスク１１で通信スケジュールが起動し、定期タスク１２に相当するタイミングでＣＡＮ送信が発生し、その間は１タスク分（定期タスク１１の分）の時間がある。また、定期タスク１６で通信スケジュールが起動し、定期タスク１６，２０に相当するそれぞれのタイミングでＣＡＮ送信が発生し、その間はそれぞれ、０タスク分、４タスク分（定期タスク１６，１７，１８，１９の分）の時間がある。以上より、３タスク分、２タスク分、１タスク分、及び４タスク分を合計して合計転送時間は１０タスク分である。
【０１４０】
同様にして、ｏｆｆｓｅｔ＝１〜４の例の場合について合計転送時間を検討すると、全て１０タスク分となる。つまり、これ以上は合計転送時間を小さくすることはできないということになる。つまり、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性は得られないということになる。
〈図９の例：ＬＩＮ→ＣＡＮ〉
次に、図９は、ＣＡＮ送信周期が定期タスク４個分、ＬＩＮ通信スケジュール周期が定期タスク２個分の場合である。そして、ＣＡＮにけるデータの送信タイミングは、それぞれ、ＬＩＮにおける定期タスク４、定期タスク８、定期タスク１２、定期タスク１６、定期タスク２０・・・のタイミングに相当しているものとする。
【０１４１】
ＣＡＮにおける送信タイミングに対する、ＬＩＮにおける通信スケジュールの開始タイミングがとり得るパターンとしては、図９の例では２通り考えられる（ｏｆｆｓｅｔ＝０，１）。
【０１４２】
ｏｆｆｓｅｔ＝０，１の段は、それぞれ、ＬＩＮにおける通信スケジュールが、定期タスク１，３，５，７，９，・・・で開始される場合（ｏｆｆｓｅｔ＝０の場合）、定期タスク２，４，６，８，１０・・・で開始される場合（ｏｆｆｓｅｔ＝１の場合）を表す。
【０１４３】
ここで、ｏｆｆｓｅｔ＝０，１のそれぞれのパターンにおいて、ＣＡＮにてデータが送信されるタイミングが、ＬＩＮにおける通信スケジュールの開始タイミングからみて幾つ目の定期タスクに相当するかを検討する。つまり、Ｎｌｃを検討する。
【０１４４】
ｏｆｆｓｅｔ＝０の例では、通信スケジュールの開始タイミング（定期タスク３）から数えて、２タスク目（Ｎｌｃ＝２）にＣＡＮにてデータが送信されている。また、通信スケジュールの開始タイミング（定期タスク７）から数えて、２タスク目（Ｎｌｃ＝２）にＣＡＮにてデータが送信されている。以降も同様に、直前の通信スケジュールの開始タイミングから数えて、２タスク目（Ｎｌｃ＝２）にＣＡＮにてデータが送信されている。
【０１４５】
このようにしてＬＩＮの通信スケジュールの開始タイミングから見てＣＡＮにおける送信タイミングが何タスク目であるか（つまりＮｌｃの値）を、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜４の期間）について抽出すると、Ｎｌｃは（２）の値をとり得る。
【０１４６】
同じようにして、ｏｆｆｓｅｔ＝１の例について抽出した場合、Ｎｌｃは（１）の値をとり得る。
【０１４７】
このように、図９の例では、Ｎｌｃが（１）、（２）の何れかをとり、（１，２）という全ての値（パターン）をとる例はないから、図３の前提条件判定処理におけるＳ２０では、全パターン出現しないというように肯定判定され（Ｓ２０：ＹＥＳ）、有効である（周期についての前提条件が成立する）と判断される。言い換えると、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとることの実効性が得られると判断される。
【０１４８】
実効性の有無について検討するために、ＣＡＮ送信周期とＬＩＮ通信スケジュール周期との最小公倍数の期間（つまり、定期タスク１〜４の期間）について、ＬＩＮの通信スケジュールの開始点を起点として、ＣＡＮ送信（転送）が発生するまでの時間の合計（合計転送時間）を検討する。
【０１４９】
ｏｆｆｓｅｔ＝０の例では、定期タスク３でＬＩＮの通信スケジュールが開始してから定期タスク４に相当するタイミングでＣＡＮ送信が発生し、その間は１タスク分（定期タスク３の分）の時間がある。以上より、合計転送時間は１タスク分である。
【０１５０】
ｏｆｆｓｅｔ＝１の例では、定期タスク４でＬＩＮの通信スケジュールが開始してから定期タスク４に相当するタイミングでＣＡＮ送信が発生し、その間はタイムラグがない。以上より、合計転送時間は０タスク分である。
【０１５１】
このような図９の例では、ｏｆｆｓｅｔ＝０の例の場合、合計転送時間が０タスク分となるようにＬＩＮにおける通信スケジュールの開始タイミングを調整する（ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとる）ことができるはずである。つまり、転送に要する時間を短くする（最短にする）ことができ、同期をとることの実効性が得られるということになる。
【０１５２】
続いて、図１０の処理について説明する。前述のように、図１０の通信スケジュール調整処理は、ＥＣＵ１０１の通信同期装置２０２が所定期間毎に実行する処理である。
【０１５３】
通信同期装置２０２は、図１０の通信スケジュール調整処理において、まずＳ１１０で、転送対象のデータについて、ＣＡＮにおけるそのデータの送信時刻（送信タイミング）或いは受信時刻（受信タイミング）を計測し、送信周期或いは受信周期を算出する。尚、ここでは、ＣＡＮ通信ドライバ２０３からの送信完了通知に基づき送信時刻（送信タイミング）を計測し、また、ＣＡＮ通信ドライバ２０３からの受信完了通知に基づき受信時刻（受信タイミング）を計測する。また、データの送信時刻（送信タイミング）は、ＬＩＮからＣＡＮへのデータ転送に際して計測し、データの受信時刻（受信タイミング）は、ＣＡＮからＬＩＮへのデータ転送に際して計測する。
【０１５４】
次に、Ｓ１２０に移行し、ＬＩＮの通信スケジュールの開始タイミングを調整可能か否かを判定する。ここでは、後述する転送開始条件とインターバル条件とが共に成立したか否かに基づき判定し、共に成立したと判断した場合に調整可能と判定する。
【０１５５】
転送開始条件は、データ転送が確実に開始されていることを確認するための条件である。例えば、（イ）車両の図示しないイグニションスイッチがオン状態であること、（ロ）起動後転送対象のデータの初受信が完了したこと、（ハ）ＬＩＮにて通信スケジュールが開始したこと、などが転送開始条件成立の要件として挙げられる。本実施形態では、（イ）〜（ハ）の要件の何れかでも成立した場合に転送開始条件が成立したと判定されるようになっている。
【０１５６】
インターバル条件は、通信スケジュールの開始タイミングの前回の調整から所定時間（以下、インターバル時間とも記載する）経過したか否かを確認するための条件である。即ち、通信スケジュールの開始タイミングの前回の調整からインターバル時間が経過した場合、インターバル条件が成立したと判定される。これは、通信スケジュールの調整の頻繁な発生を防止する趣旨のものである。通信スケジュールの調整が頻繁に発生すると、かえってデータ転送が非効率になってしまったり、ＬＩＮにて通信スケジュールが開始されなくなってしまったりするという弊害が生じてしまう可能性もあるためである。尚、インターバル時間は、例えば、ＣＡＮ送受信周期（Ｔｃ）とＬＩＮ通信スケジュール周期（Ｔｌ）との最小公倍数に定期タスクの時間を乗じた時間以上とすることができる。
【０１５７】
Ｓ１２０で調整可能と判定した場合（Ｓ１２０：ＹＥＳ）はＳ１３０に進み、Ｓ１２０で調整可能でないと判定した場合（Ｓ１２０：ＮＯ）には再びＳ１１０に戻る。Ｓ１２０から戻ったＳ１１０では、他の転送対象のデータについて、送信時刻（送信タイミング）或いは受信時刻（受信タイミング）を計測する。そして、その後の処理を続ける。
【０１５８】
Ｓ１３０では、転送対象のデータについてのＣＡＮ送受信周期と、ＬＩＮ通信スケジュール周期とが同一であるか否かを判定し、同一であると判定すると（Ｓ１３０：：ＹＥＳ）、Ｓ１４０に移行し、同一でないと判定すると（Ｓ１３０：ＮＯ）、Ｓ１５０に移行する。ＣＡＮ送受信周期とＬＩＮ通信スケジュール周期とが同一である場合は、それらの開始タイミングの同期をとれば、ＣＡＮの送受信のタイミングとＬＩＮの通信スケジュールの開始タイミングとが完全に一致することとなる。一方、ＣＡＮ送受信周期とＬＩＮ通信スケジュール周期とが同一でない場合は、図４〜９の例に示したように調整不要の場合もあるため、調整の要否を判定する必要がある。
【０１５９】
Ｓ１４０では、オフセットするタスク数を算出する。具体的に、ＬＩＮの通信スケジュールの開始タイミングの調整量を算出する。
【０１６０】
ここで、ＣＡＮからＬＩＮへのデータ転送に際しては、ＣＡＮにおける受信が発生した直後の定期タスクにおいてＬＩＮの通信スケジュールが開始されるようにすると、ＣＡＮからＬＩＮへのデータ転送の遅れが最も少なくなる。そこで、Ｓ１４０の処理では、ＣＡＮからＬＩＮへのデータ転送に際してオフセットするタスク数を以下の（ａ）式及び（ｂ）式により算出する。
【０１６１】
ＯＦＳｃｌ＝ｎ１・Ｔｃ−（Ｔｌ−Ｎｃｌ）・・・（ａ）式
ｎ１＝ＣＥＩＬＩＮＧ（（Ｔｌ−Ｎｃｌ）／Ｔｃ）・・・（ｂ）式
ＯＦＳｃｌ：オフセットするタスク数
ＣＥＩＬＩＮＧ：小数点以下切り上げを行う関数
Ｔｌ：通信スケジュール周期（定期タスクの数）
Ｔｃ：ＣＡＮ送受信周期（定期タスクの数）
次に、ＬＩＮからＣＡＮへのデータ転送に際しては、ＣＡＮにおける送信が発生する直前の定期タスクにおいてＬＩＮの通信スケジュールが終了すると、ＬＩＮからＣＡＮへのデータ転送の遅れが最も少なくなる。そこで、Ｓ１４０の処理では、ＬＩＮからＣＡＮへのデータ転送に際してオフセットするタスク数を以下の（ｃ）式及び（ｄ）式により算出する。
【０１６２】
ＯＦＳｃｌ＝（ｎ２・Ｔｃ−１）−（Ｔｌ−Ｎｌｃ）・・・（ｃ）式
ｎ２＝１＋ＦＬＯＯＲ（（Ｔｌ−Ｎｌｃ）／Ｔｃ）・・・（ｄ）式
ＯＦＳｃｌ：オフセットするタスク数
ＦＬＯＯＲ：小数点以下切り捨てを行う関数
Ｓ１４０の後はＳ１８０に移行し、Ｓ１４０で算出したオフセットするタスク数に基づき、通信スケジュールの調整指示をＬＩＮ通信スケジューラ２０６に出力する。そして再びＳ１１０に戻る。尚、オフセットするタスク数がゼロである場合には調整指示の通知は行わない。
【０１６３】
一方、Ｓ１３０にて否定判定して移行したＳ１５０では、Ｓ１１０の計測結果に基づき、前述のＮｃｌ或いはＮｌｃの出現パターンを判別する。例えば、前述のインターバル時間中においてＮｃｌ或いはＮｌｃの値を計測することで、その出現パターンを判別できる。
【０１６４】
Ｓ１５０の後はＳ１６０に進み、通信スケジュールの開始タイミングの調整の要否を判定する。本実施形態では、Ｎｃｌ或いはＮｌｃの出現パターン毎に通信スケジュールの開始タイミングの調整が有効となるのか否かを示す情報（以下、調整要否情報とも記載する）を予めＥＣＵ１０１において記憶しておく。そして、その調整要否情報を参照することによって調整の要否を判定する。例えば、図４の例でみると、ｏｆｆｓｅｔ＝０，２，４の例の場合のようにＮｃｌの出現パターンが（４，２、６）となる場合は調整不要と設定しておき、ｏｆｆｓｅｔ＝１，３，５の例の場合のようにＮｌｃの出現パターンが（３，１，５）となる場合は調整要と設定しておく。
【０１６５】
Ｓ１６０で調整が必要でないと判定すると（Ｓ１６０：ＮＯ）、再びＳ１１０に戻る。一方、Ｓ１６０で調整が必要であると判定すると（Ｓ１６０：ＹＥＳ）、Ｓ１７０に移行する。Ｓ１７０では、オフセットするタスク数を算出する。本実施形態では、図４〜９に示すような各パターン毎に、合計転送時間を最短とするためにオフセットすべきタスク数を予めＥＣＵ１０１において記憶しておく。そして、その情報を参照してオフセットするタスク数を算出できるようにする。例えば図４の例でみると、ｏｆｆｓｅｔ＝１の例では、通信スケジュールの開始タイミングを１タスク分だけオフセットする（早くする）と、ｏｆｆｓｅｔ＝０の例と一致し、合計転送時間が２タスク分まで減少する。したがって、例えば図４のｏｆｆｓｅｔ＝１のパターンをとる場合はオフセットするタスク数は１とする、という情報を予め持っておくようにする。
【０１６６】
Ｓ１７０の後はＳ１８０に移行し、通信スケジュールの開始タイミングの調整指示をＬＩＮ通信スケジューラ２０６に出力する。
【０１６７】
次に、図１１の処理について説明する。前述のように、図１１の通信スケジュール開始処理は、ＥＣＵ１０１のＬＩＮ通信スケジューラ２０６が所定期間毎に実行する。
【０１６８】
ＬＩＮ通信スケジューラ２０６は、図１１の通信スケジュール開始処理において、まずＳ２１０で、通信同期装置２０２からの通信スケジュールの調整指示を受けたか否かを判定する。通信スケジュールの調整指示は、前述の図１０のＳ１８０において通信同期装置２０２から出力される。
【０１６９】
Ｓ２１０において調整指示を受けていないと判定すると（Ｓ２１０：ＮＯ）、Ｓ２３０に移行し、予め設定されているタイミング（定期タスク）で通信スケジュールを開始（起動）する。そしてその後、当該処理を終了する。
【０１７０】
一方、Ｓ２１０で調整指示を受けたと判定すると（Ｓ２１０：ＹＥＳ）、Ｓ２２０に移行し、予め設定されているタイミングから、オフセットするタスク数分の時間が経過したか否かを判定する。オフセットするタスク数の情報は、通信同期装置２０２からの調整指示に含まれている。
【０１７１】
Ｓ２２０でオフセットするタスク数分の時間が経過していないと判定すると（Ｓ２２０：ＮＯ）、再びＳ２２０の処理を繰り返す（オフセットするタスク数分の時間が経過するまで待機する）。一方、Ｓ２２０でオフセットするタスク数分の時間が経過したと判定すると（Ｓ２２０：ＹＥＳ）、同期タイミングと判断してＳ２３０に移行し、通信スケジュールを開始する。そしてその後、当該処理を終了する。
【０１７２】
以上説明したように、本実施形態においては、ＥＣＵ１０１は、ＣＡＮとＬＩＮとに接続するＥＣＵ１０１において、そのＣＡＮ及びＬＩＮ間のデータ転送に際し、転送に要する時間が最短となるようにＬＩＮにおける通信スケジュールの開始タイミングを調整するようになっている。具体的には、ＣＡＮからＬＩＮへのデータ転送に際し、ＣＡＮにおける受信タイミングとＬＩＮにおける送信タイミングとが同期するように、ＬＩＮにて通信スケジュールが開始されるようにする。このため、ＣＡＮで受信されたデータが即座にＬＩＮに転送されるようになる。また、ＬＩＮからＣＡＮへのデータ転送に際し、ＣＡＮにおける送信タイミングとＬＩＮにおける受信タイミングとが同期するように、ＬＩＮにて通信スケジュールが開始されるようにする。このため、ＬＩＮで受信されたデータが即座にＣＡＮに転送されるようになる。
【０１７３】
このような本実施形態では、ＣＡＮからＬＩＮへのデータ転送、或いはＬＩＮからＣＡＮへのデータ転送に際し、タイムラグの発生が抑えられるようになっている。これによれば、ＣＡＮからＬＩＮへのデータ転送、或いはＬＩＮからＣＡＮへのデータ転送がスムーズなものとなり、転送効率の向上に寄与できる。
【０１７４】
尚、本実施形態において、Ｓ１１０の処理が検出手段に相当し、Ｓ１４０、Ｓ１７０の処理が算出手段に相当している。
［変形例１］
次に、上記実施形態の変形例１について、図１２、図１３を用いて説明する。尚、図１２はＣＡＮからＬＩＮへのデータ転送の態様を表し、図１３はＬＩＮからＣＡＮへのデータ転送の態様を表す。
【０１７５】
本変形例１では、図１２に示すように、４つのフレームの送受信でＬＩＮの通信スケジュールが構成される。また、ＬＩＮ通信スケジュール周期は４タスクである。具体的には、データＡの送信、データＢの受信、データＣの受信、データＤの送信の順で通信スケジュールが構成され、そのデータＡの送信、データＢの受信、データＣの受信、データＤの送信のそれぞれで定期タスク１個分を占める。
【０１７６】
図１２において、前述した図１０、図１１の処理によりＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとった場合、ＬＩＮ通信スケジュールパターン（１）に示すように、ＣＡＮの受信タイミングの直後の定期タスクでＬＩＮの通信スケジュールが開始されるようになる。前述のようにＬＩＮにおける通信スケジュールはデータＡの送信、データＢの受信、データＣの受信、データＤの送信の順で構成されるから、データＡがＣＡＮからＬＩＮに最短で転送され得る。
【０１７７】
ここで、例えばデータＤを最短で転送しようとする場合には、ＬＩＮ通信スケジュールパターン（２）に示すように、ＬＩＮの通信スケジュールの開始タイミングを１タスク分オフセットする（遅らせる）。これにより、「データＤの送信」というタスクがＣＡＮにおける受信の直後に発生することになるため、データＤがＣＡＮからＬＩＮに最短で転送され得るようになる。
【０１７８】
次に、図１３において、前述した図１０、図１１の処理によりＣＡＮ送信周期とＬＩＮ通信スケジュールとの同期をとった場合、ＬＩＮ通信スケジュールパターン（３）に示すように、データＣがＬＩＮからＣＡＮに最短で転送され得る。
【０１７９】
ここで、例えばデータＢを最短で転送しようとする場合には、ＬＩＮ通信スケジュールパターン（４）に示すように、ＬＩＮの通信スケジュールの開始タイミングを１タスク分オフセットする（遅らせる）。これにより、「データＢの受信」というタスクがＣＡＮにおける送信の直前に発生することとなるため、データＢがＬＩＮからＣＡＮに最短で転送され得るようになる。
【０１８０】
以上のように、本変形例１は、ＣＡＮ送受信周期とＬＩＮ通信スケジュール周期との同期をとり、さらに、最短で転送したいデータに合わせて追加でオフセットを実行するものである。
【０１８１】
これによれば、ＬＩＮの通信スケジュールが複数のフレームの送受信で構成される場合において、複数のフレームのうち所望のフレーム（所望のデータ）を対象として転送時間を最短にすることができるようになる。これによれば、所望のデータを最短で転送することをより確実に実現できる。
【０１８２】
尚、最短で転送したいデータは予め設定されるように構成しても良いが、以下に示す変形例２のように、最短で転送したいデータが動的に変更されるように構成しても良い。
［変形例２］
本変形例２について、図１４を用いて説明する。尚、本変形例２は、図３の前提条件判定処理で無効である（周期に関する前提条件が成立しない）と判断される場合でも適用することができる。
【０１８３】
図１４の例では、ＬＩＮの通信スケジュールは、送信フレームαの送受信（データＡの送受信）、及び送信フレームβの送受信（データＢの送受信）の順で構成されるものとする。また、ＬＩＮ通信スケジュール周期は６タスクである。具体的には、送信フレームαの送受信、及び送信フレームβの送受信でそれぞれ３タスク分を占める。
【０１８４】
一方、ＣＡＮにおいては、ＣＡＮフレーム１（データＡ）、ＣＡＮフレーム２（データＢ）が、それぞれ、６タスクに相当する周期で受信されるものとする。例えば、ＣＡＮフレーム１が、定期タスク２の直後、定期タスク８の直後のタイミングでそれぞれ受信され、ＣＡＮフレーム２が、例えば定期タスク３の直後、定期タスク９の直後のタイミングでそれぞれ受信される。
【０１８５】
ＣＡＮフレーム１（データＡ）に同期して転送を行う場合（データＡを最短で転送する場合）、図１４のＬＩＮ通信スケジュールパターン（５）に示すように、ＣＡＮフレーム１の受信の直後の定期タスクで通信スケジュールが開始するように、その通信スケジュールの開始タイミングが調整される（図１０、図１１の処理）。これにより、データＡが最短で転送され得るようになる。
【０１８６】
一方、データＢについてであるが、ＬＩＮ通信スケジュールパターン（５）では、定期タスク３の直後にＣＡＮフレーム２（データＢ）がＣＡＮにて受信されてから、定期タスク６にて送信フレームβ（データＢ）がＬＩＮに送信されるまでの間、転送に遅れが生じることとなる。
【０１８７】
ここで、本変形例２では、データＢを最短で転送しようとする場合、データＢを格納するＣＡＮフレーム２に、データＢについて同期をとるための同期指示（以下、データＢ同期指示とも記載する）が格納される。
【０１８８】
ＣＡＮフレーム２において、データＢとともに、データＢ同期指示が格納されている場合、データＢが最短で転送され得るように、ＬＩＮの通信スケジュールの開始タイミングが調整される。具体的には、ＬＩＮ通信スケジュールパターン（６）に示すように、ＣＡＮフレーム２の受信の直後の定期タスクで「送信フレームβの送受信」のタスクが発生するように、ＬＩＮの通信スケジュールの開始タイミングがオフセットされる。
【０１８９】
このオフセットの手順をより具体的に説明すると、まず、ＣＡＮフレーム２の受信周期とＬＩＮ通信スケジュール周期とが同期するように、ＬＩＮの通信スケジュールの開始タイミングが調整される（図１０の処理）。加えて、ＬＩＮの通信スケジュールの開始タイミングが、送信フレームαの送受信に要する時間（図１４の例では３タスク分）だけ減算される（早くなる）。このような手順により、ＣＡＮフレーム２の受信の直後の定期タスクで「送信フレームβの送受信」のタスクが発生するようになり、データＢが最短で転送され得るようになる。
【０１９０】
尚、ここでは、ＣＡＮからＬＩＮへのデータ転送の場合について説明したが、ＬＩＮからＣＡＮへのデータ転送の場合も同様の手法で調整できる。
［変形例３］
次に、変形例３について図１５を用いて説明する。
【０１９１】
図１５の例は、ＣＡＮからＬＩＮにデータを転送する場合の態様を表す。ＣＡＮ受信周期は４タスクであり、例えば、定期タスク４の直後、定期タスク８の直後、定期タスク１２の直後、定期タスク１６の直後、のタイミングで、ＣＡＮにて受信が発生するものとする。
【０１９２】
また、ＬＩＮの通信スケジュールは送信フレームの送受信、及び受信フレームの送受信の順に構成され、ＬＩＮ通信スケジュール周期は４タスクであるとする。
【０１９３】
図１５における「同期前」の例に示すように、ＬＩＮの通信スケジュールの開始タイミングが定期タスク３，７，１１，１５・・・であるとすると、例えば定期タスク４の直後にＣＡＮにて受信されたデータが最短でＬＩＮに転送されるようにするには、ＬＩＮの通信スケジュールの開始を、２／４周期（つまり２タスク分）だけ待つ必要がある。具体的には、ＬＩＮの通信スケジュールが、定期タスク５，９，１３・・・で開始されるようにする必要がある。
【０１９４】
この本変形例３では、ＬＩＮの通信スケジュールの開始タイミングを徐々にずらし、ＣＡＮ受信周期とＬＩＮ通信スケジュール周期との同期をとるようになっている。
【０１９５】
まず、図１５の「同期処理（１回目）」の段に示すように、１回目の同期処理にて、ＬＩＮの通信スケジュールの開始タイミングを１タスク分だけ遅らせる（１タスク分待機する）。具体的には、本来は定期タスク７で開始される通信スケジュールを、１タスク分後の定期タスク８で開始させる。
【０１９６】
続いて、図１５の「同期処理（２回目）」の段に示すように、２回目の同期処理にて、ＬＩＮの通信スケジュールの開始タイミングをさらに１タスク分だけ遅らせる。その後は、図示は省略するが４タスクの周期で通信スケジュールを開始する。
【０１９７】
これにより、ＬＩＮの通信スケジュールの開始タイミングが、目標とするタイミングに一致する。即ち、ＬＩＮの通信スケジュールが定期タスク１３，１７・・・で開始されるようになる。言い換えると、ＣＡＮにおける受信の発生直後の定期タスクにて、ＬＩＮの通信スケジュールが開始されるようになる。
【０１９８】
このような変形例３のように、ＬＩＮの通信スケジュールの開始タイミングを１回の同期処理で調整するのではなく複数回の同期処理に分けて徐々に調整することにより、１回あたりの調整量（オフセット量）を小さくすることができる。言い換えると、通信スケジュールの開始タイミングが１回の調整で大幅に変更されないようにできる。通信スケジュールの開始タイミングが１回の調整で大幅に変更されてしまうと、ネットワーク上においてその変更を認識できない装置など（例えば図１における制御装置１０３）が、通信に関する故障が生じたとか通信途絶が生じたというように誤判断する可能性もあるが、本変形例３の構成によれば、そのような問題が生じることを回避し得る。
【０１９９】
尚、ここでは、ＣＡＮからＬＩＮへのデータ転送の場合について説明したが、ＬＩＮからＣＡＮへのデータ転送の場合も同様の手法で調整できる。
［変形例４］
次に、変形例４について図１６を用いて説明する。尚、本変形例４は、図３の前提条件判定処理で無効である（周期に関する前提条件が成立しない）と判断される場合でも適用することができる。
【０２００】
図１６の例は、ＣＡＮからＬＩＮにデータを転送する場合の態様を表す。ＣＡＮにおいては、ＣＡＮフレーム１（データＡ）、ＣＡＮフレーム２（データＢ）が、それぞれ、６タスクに相当する周期で受信されるものとする。より具体的には、ＣＡＮフレーム１が、例えば定期タスク２の直後、定期タスク８の直後のタイミングでそれぞれ受信され、ＣＡＮフレーム２が、例えば定期タスク５の直後、定期タスク１１の直後のタイミングでそれぞれ受信される。
【０２０１】
また、ＬＩＮの通信スケジュールは送信フレームの送受信（データＡ及びデータＢの送受信）、及び受信フレームの送受信（データＣの送受信）の順に構成され、ＬＩＮ通信スケジュール周期は６タスクであるとする。
【０２０２】
そして、図１６におけるＬＩＮ通信スケジュールパターン（７）の例では、データＡが最短で転送されるように構成されている。具体的には、ＬＩＮの通信スケジュールが、ＣＡＮフレーム１の受信（データＡの受信）が発生した直後の定期タスクで開始されるようになっている。一方、データＢについてであるが、例えば定期タスク５の直後にＣＡＮフレーム２（データＢ）がＣＡＮにて受信されてから、定期タスク９にて送信フレーム（データＡ及びデータＢ）がＬＩＮにて送受信されるまでの間、転送に遅れが生じることとなる。
【０２０３】
本変形例４では、例えばデータＢを緊急に転送しようとする場合、データＢを格納するＣＡＮフレーム２に、データＢが緊急で転送されるべきデータ（以下、緊急データとも記載する）である旨の情報が格納される。
【０２０４】
ＣＡＮフレーム２において、データＢとともに、緊急データの情報が格納されている場合、データＢが緊急（最短）で転送され得るように、ＬＩＮの通信スケジュールの開始タイミングが調整される。具体的には、現在の通信スケジュールが中止され、ＬＩＮ通信スケジュールパターン（８）に示すように、データＢをすぐに転送できるような新たな通信スケジュールが開始される。
【０２０５】
例えば、図１６の例では、ＣＡＮにてＣＡＮフレーム２が受信された後、定期タスク６にて本来発生するはずであった「受信フレームの送受信（データＣの送受信）」のタスクがキャンセルされ（現状の通信スケジュールがキャンセルされ）、定期タスク７にて新たに通信スケジュールが開始される。これにより、ＣＡＮにて受信されたＣＡＮフレーム２（データＢ）が、即座にＬＩＮに転送され得るようになる。
【０２０６】
このような変形例４によれば、受信フレームの送受信(データＣの送受信)の終了まで待つことなく、すぐに所望のデータＢをＣＡＮからＬＩＮに転送できる。
【０２０７】
尚、ここでは、ＣＡＮからＬＩＮへのデータ転送の場合について説明したが、ＬＩＮからＣＡＮへのデータ転送の場合も同様である。ＬＩＮにおける受信フレームに、緊急データである旨の情報が格納されるようにすれば良い。受信フレームに緊急データである旨の情報が格納されている場合、その受信フレームの受信タイミングとＣＡＮにおける送信タイミングとが同期するように、ＬＩＮにおける通信スケジュールの開始タイミングを調整すれば良い。
［変形例５］
次に、変形例５について図１７、図１８を用いて説明する。
【０２０８】
上記実施形態では、ある１つのデータを対象として、そのデータが最短で転送されるように、ＬＩＮにおける通信スケジュールの開始タイミングを調整するようにしていた。本変形例５は、複数のデータを対象とし、それらのデータがなるべく遅れなく転送されるようにするものである。
【０２０９】
図１７の例において、転送対象のデータとして、ＣＡＮにてＣＡＮフレーム１、ＣＡＮフレーム２、ＣＡＮフレーム３の３種類が受信されるものとする。尚、ＣＡＮフレーム１、ＣＡＮフレーム２の受信周期は１６［ｍｓ］であり、ＣＡＮフレーム３の受信周期は２４［ｍｓ］である。
【０２１０】
ここで、本変形例では、ＥＣＵ１０１において以下のような処理が実行されるようにする。
【０２１１】
まず、予め設定された所定の長さの区間毎に各フレームの受信タイミングを検出する。ここでは、１６［ｍｓｅｃ］の期間を１つの区間として受信タイミングを検出する。
【０２１２】
そして、複数の区間の検出結果を重ね合わせる。具体的に、１〜１６［ｍｓｅｃ］、１６〜３２［ｍｓｅｃ］、・・・ｎ×１６〜（ｎ＋１）×１６［ｍｓｅｃ］の区間の検出結果を重ね合わる。
【０２１３】
そして、受信タイミングのヒストグラムを作成する。
【０２１４】
この場合のヒストグラムを図１８に示す。１〜１６［ｍｓｅｃ］、１６〜３２［ｍｓｅｃ］、・・・ｎ×１６〜（ｎ＋１）×１６［ｍｓｅｃ］の区間の検出結果を重ね合わせ、まず、ＣＡＮフレーム１、ＣＡＮフレーム２、及びＣＡＮフレーム３のそれぞれについて、受信タイミングのヒストグラムを作成する。
【０２１５】
ＣＡＮフレーム１は定期タスク[ｎ×１６＋１]のタイミングで受信されるため、ＣＡＮフレーム１の受信タイミングのピークは定期タスク[ｎ×１６＋１]の箇所に現れる。
【０２１６】
同様に、ＣＡＮフレーム２は定期タスク[ｎ×１６＋３]のタイミングで受信されるため、ＣＡＮフレーム１の受信タイミングのピークは定期タスク[ｎ×１６＋３]の箇所に現れる。
【０２１７】
ＣＡＮフレーム３は定期タスク[ｎ×１６＋４]、及び定期タスク[ｎ×１６＋１２]のタイミングで受信されることとなり、ＣＡＮフレーム３の受信タイミングのピークは定期タスク[ｎ×１６＋４]と定期タスク[ｎ×１６＋１２]とに現れる。
【０２１８】
つぎに、ＣＡＮフレーム１、ＣＡＮフレーム２、及びＣＡＮフレーム３それぞれのヒストグラムを全て合成する。そうすると、図１８に示すように、ピークがおおよそ定期タスク[ｎ×１６＋２]或いは定期タスク[ｎ×１６＋３]のタイミングと、定期タスク[ｎ×１６＋１２]とに現れることが分かり、特に前者のピークが大きい。つまり、定期タスク[ｎ×１６＋２]或いは定期タスク[ｎ×１６＋３]のタイミングで、ＣＡＮにおける受信が最も多く発生していることが分かる。
【０２１９】
そこで、本変形例５では、そのピークの直後の定期タスクにてＬＩＮの通信スケジュールが開始されるように、ＬＩＮの通信スケジュールの開始タイミングを調整する。
【０２２０】
このような本変形例５によれば、複数のデータについて平均的に、転送遅れが大きくなってしまうことを防止し得る。
【０２２１】
尚、ここでは、ＣＡＮからＬＩＮへのデータ転送の場合について説明したが、ＬＩＮからＣＡＮへのデータ転送の場合も同様である。この場合、ＣＡＮにおける送信タイミングのヒストグラムを作成し、ＣＡＮにおける送信タイミングのピークとＬＩＮにおける受信タイミングとが同期するように、通信スケジュールの開始タイミングを調整すれば良い。
［変形例６］
上記実施形態では、ＣＡＮ及びＬＩＮにて実際に送受信されるデータを対象に、最短で転送したいデータを定め、そのデータの送受信タイミングを検出してＣＡＮにおける送受信タイミングとＬＩＮにおける送受信タイミング（ＬＩＮにおける通信スケジュールの開始タイミング）との同期をとるようにしていた。
【０２２２】
一方、ＣＡＮ及びＬＩＮにて実際に送受信されるデータに代えて、ダミーデータを用いてＬＩＮの通信スケジュールの開始タイミングを調整するようにしても良い。
【０２２３】
具体的に、ＣＡＮ通信ドライバ２０３(図２参照)を介してＣＡＮにてダミーデータを送受信し、また、ＬＩＮ通信ドライバ２０５を介してＬＩＮにてダミーデータを送受信するようにすれば良い。ダミーデータの送受信タイミングは、予め設定しておくことができる。例えば、外部コンピュータにおいて車両ネットワーク１００を仮想的に構築して動作のシミュレーションを実行することで、所定のデータの送受信タイミングを割り出すことができ、このようにして割り出された送受信タイミングをＥＣＵ１０１において予め設定しておけば良い。
【０２２４】
ダミーデータを用いてＬＩＮにおける通信スケジュールの開始タイミングを調整するような構成によれば、例えば、ＥＣＵ１０１がデータ転送を頻繁に行わなくてはならないときや制御装置１０３の制御中などにＬＩＮの通信スケジュールの開始タイミングを調整することを避け、例えば、起動直後の初期化処理中などにＬＩＮの通信スケジュールの開始タイミングを調整しておくようにすることができる。これによれば、データ転送の効率化により寄与することができる。
【０２２５】
尚、この場合、例えばＣＡＮ通信ドライバ２０３、ＬＩＮ通信ドライバ２０５がダミーデータ送受信手段に相当する。
［変形例７］
また、上記実施形態においては、ＥＣＵ１０１は、ＬＩＮにおける通信スケジュールの開始タイミングの変更の伴い、その開始タイミングを変更することを表す情報をＬＩＮに送出するようにしても良い。
【０２２６】
これによれば、例えばＬＩＮ上の通信装置は通信スケジュールの開始タイミングの変更を認識し得るようになる。このため、ＬＩＮ上の通信装置において、変更が原因で通信に異常が生じたと誤判断されたり通信途絶と誤判断されたりしてしまうことを防止することができる。
【０２２７】
以上、本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、本発明の技術範囲内において種々の形態をとることができる。
【０２２８】
例えば、上記実施形態において、車両ネットワーク１００の構成は一例であり、例えばＥＣＵや制御対象が更に複数接続される構成でも良い。
【０２２９】
また、上記実施形態の転送開始条件の判定において、（イ）車両の図示しないイグニションスイッチがオン状態であること、（ロ）起動後転送対象のデータの初受信が完了したこと、（ハ）ＬＩＮにて通信スケジュールが開始したこと、の全てが成立した場合に転送開始条件が成立したと判定されるようにしても良い。
【０２３０】
また、上記の変形例５において、所定の区間の長さは１６［ｍｓｅｃ］としているが、どのような長さにしても良い。
【０２３１】
尚、上記変形例１〜７の構成は組み合わせても良い。
【符号の説明】
【０２３２】
１００…車両ネットワーク、２０２…通信同期装置、２０３…ＣＡＮ通信ドライバ、２０４…データベース、２０５…ＬＩＮ通信ドライバ、２０６…ＬＩＮ通信スケジューラ、２０７…ＣＡＮ通信線、２０８…ＬＩＮ通信線、３００…車両ネットワーク、３０３…制御装置、３０４…ワイヤハーネス、３０６…ワイヤハーネス、３０７…ＣＡＮ通信線、４００…車両ネットワーク、４０３…制御装置、４０４…ＬＩＮ通信線、４０５…ＣＡＮ通信線。
【図３】
2010187323.tif 000003
【図４】
2010187323.tif 000004
【図５】
2010187323.tif 000005
【図６】
2010187323.tif 000006
【図７】
2010187323.tif 000007
【図８】
2010187323.tif 000008
【図９】
2010187323.tif 000009
【図１０】
2010187323.tif 000010
【図１１】
2010187323.tif 000011
【図１２】
2010187323.tif 000012
【図１３】
2010187323.tif 000013
【図１４】
2010187323.tif 000014
【図１５】
2010187323.tif 000015
【図１６】
2010187323.tif 000016
【図１７】
2010187323.tif 000017
【図１８】
2010187323.tif 000018
【図１９】
2010187323.tif 000019
【図２１】
2010187323.tif 000020
【図２２】
2010187323.tif 000021
【図２３】
2010187323.tif 000022
【図２４】
2010187323.tif 000023
【図１】
2010187323.tif 000024
【図２】
2010187323.tif 000025
【図２０】
2010187323.tif 000026