(57)【要約】【課題】車両用の電子制御装置で使用するＬＩＮ通信装置では、運転状況が変化しても固定的な通信スケジュールに従って通信フレームが送信される。【解決手段】車両用のＬＩＮ通信装置に、運転状況に応じて通信スケジュールテーブルの内容を任意に変更する制御部を搭載する。また、車両用のＬＩＮ通信装置に、運転状況に応じて通信フレームの送受信タイミングを任意に変更する制御部を搭載する。なお、運転状況は、車両状態を示す情報に基づいて判断することが望ましい。【選択図】図１
2010268066.tif 000002
【特許請求の範囲】
【請求項１】
ＬＩＮ通信を実行する制御手段を搭載するＬＩＮ通信装置であって、
上記制御手段が、
ＬＩＮ通信用の通信フレームの通信順序を示す通信スケジュールを規定したスケジュールテーブルを記憶する記憶部と、
予め設定した変更事象の検知時に、前記通信スケジュールテーブルに規定された通信スケジュールの内容を任意に変更する処理手段と
を有することを特徴とするＬＩＮ通信装置。
【請求項２】
前記通信スケジュールの内容の変更は、
前記スケジュールテーブルで規定する通信順序及び又は通信フレームの数の変更により実現する
ことを特徴とする請求項１に記載のＬＩＮ通信装置。
【請求項３】
ＬＩＮ通信を実行する制御手段を搭載するＬＩＮ通信装置であって、
上記制御手段が、
ＬＩＮ通信用の通信フレームの通信順序を示す通信スケジュールを規定したスケジュールテーブルを記憶する記憶部と、
予め設定した変更事象の検知時に、通信スケジュールの送受信タイミングを任意に変更する処理手段と
を有することを特徴とするＬＩＮ通信装置。
【請求項４】
前記通信スケジュールの送受信タイミングの変更は、
前記スケジュールテーブルから読み出す通信スケジュールの読み出し位置の変更により実現する
ことを特徴とする請求項３に記載のＬＩＮ通信装置。
【請求項５】
前記通信スケジュールの送受信タイミングの変更は、通信フレームの送信周期の変更により実現する
ことを特徴とする請求項３に記載のＬＩＮ通信装置。
【請求項６】
前記変更事象の検知は、車両状態を示す情報の変化の検知により行なう
ことを特徴とする請求項１〜５のいずれか１項に記載のＬＩＮ通信装置。
【請求項７】
前記制御手段は、マスタ装置として動作するエンジン制御ユニットに搭載される
ことを特徴とする請求項１〜６のいずれか１項に記載のＬＩＮ通信装置。
【請求項８】
ＬＩＮ通信を実行するＬＩＮ通信装置に搭載された制御手段によって実行されるＬＩＮ通信制御方法であって、
予め設定した変更事象の検知時に、通信スケジュールテーブルにおいて規定されている、ＬＩＮ通信用の通信フレームの通信順序を示す通信スケジュールの内容を任意に変更する処理
を有することを特徴とするＬＩＮ通信制御方法。
【請求項９】
ＬＩＮ通信を実行するＬＩＮ通信装置に搭載された制御手段によって実行されるＬＩＮ通信制御方法であって、
予め設定した変更事象の検知時に、通信スケジュールテーブルにおいて規定されている、ＬＩＮ通信用の通信フレームの通信順序を示す通信スケジュールの送受信タイミングを任意に変更する処理
を有することを特徴とするＬＩＮ通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子制御装置に関する。例えばスケジュールテーブルに従ってＬＩＮ（Local Interconnect Network）通信プロトコルによる通信を行うＬＩＮ通信装置及びＬＩＮ通信制御方法に関する。
【背景技術】
【０００２】
ＬＩＮ通信プロトコルとは、車載ＬＡＮのコストダウンを図ることを目的に、自動車メーカ等が提唱しているシリアル通信プロトコルである。ＬＩＮ通信プロトコルを用いれば、ゲートウェイを介してコントロールエリアネットワーク（以下、「ＣＡＮ（Controller Area Network）」という。）に接続することができる。このＬＩＮ通信プロトコルのネットワーク構成はシングルマスタ−マルチフレーズ方式であり、伝送路には廉価なシングルワイヤ方式を採用し、ＵＡＲＴ（半２重方式、転送データ長８ビット、１ストップビット）通信方式を採用し、伝送ボーレートの最速値は２０ｋｂｐｓである。
【０００３】
ＬＩＮ通信プロトコルの通信フレームの構成を図７に示す。図７に示すメッセージフレーム（Message Frame）は、ヘッダ（Header）と、レスポンス（Response）と、レスポンススペース（Response Space）で構成される。なお、ヘッダは、シンクブレイク部（Synch Brake）、シンク部（Synch Field）、識別部（Identifier Field）で構成される。レスポンスは、複数のデータ部（Data Field）とチェックサム部（Checksum Field）で構成される。レスポンススペースは、ヘッダとレスポンスの間に配置される。
【０００４】
通信フレームは、マスタ装置とスレーブ装置が通信する際に送受信される。各通信フレームは識別部によって一意に決定され、マスタ装置の通信先情報及びスレーブ装置に対する要求命令情報も識別部により判別される。通信フレームの通信順序及び送受信タイミングは、スケジュールテーブルで規定され、ＬＩＮネットワーク内で送受信する通信フレームが決定される。
【０００５】
ＥＣＵ（Engine Control Unit）は、車両の制御機構との間で信号をやり取りし、車両を電子的に制御する。例えばＥＣＵは、車両に装備されたセンサ群から検出された車速、エンジン回転数、空気流入量その他の車両情報を入力し、当該車両情報に基づいて所定の演算処理を実行し、その演算結果を車両に装備された電動スロットルやスタータ噴射弁等の制御機構に送出し、燃料の噴射量や流入空気量の制御等を実行する。
【０００６】
このような電子制御装置が様々な車載部品で使用されている。このため、車載ＬＡＮ（又は車内ＬＡＮ）技術が発展している。例えば走行系の電子制御装置間では、各センサ情報を共有するために、ＣＡＮプロトコル等を使用してセンサ値を高速度通信プロトコルにより送受信する。一方、ボディ系の電子制御装置間では、高速度による通信の必要性が相対的に小さい。このため、ボディ系の電子制御装置間では、低速度通信プロトコルであるＬＩＮ通信プロトコルを使用してデータの送受信を行っている。
【０００７】
従来技術では、運転状況が変化しても、通信スケジュールは常に一定である。なお、特許文献１には、車両用電子制御装置と通信する電子制御装置の起動状態に応じて、使用するスケジュールテーブルを切り替える車両用の電子制御装置が提案されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２１３７１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、運転状況によって、特定の通信フレームを優先的に通信すべき場合がある。例えばアイドルストップ後にエンジンを再始動する場合、ＥＣＵとエンジンを再始動する装置であるＩＳＧ（Integrated Starter Generator）との間のＬＩＮ通信では、エンジンを再始動する要求命令情報を含んだ通信フレームを優先して通信する必要がある。
【００１０】
ところが、従来技術では、このような場合でも通信スケジュールは変更されずに用いられている。すなわち、運転状況が変化しても通信スケジュールは変更されなかった。なお、特許文献１は、車両用の電子制御装置と通信する電子制御装置の起動状態に応じてスケジュールテーブルを切り替える技術を開示しているが、運転状況に応じて通信スケジュールを変更することについては開示されていない。このため、特許文献１を適用したＥＣＵでは、運転状況の変化の検知時にも、予め規定された通信スケジュールがそのまま使用される。
【課題を解決するための手段】
【００１１】
そこで、発明者は、ＬＩＮ通信装置に、運転状況に応じてスケジュールテーブルの内容を任意に変更する制御部を搭載する。また、発明者は、ＬＩＮ通信装置に、運転状況に応じて通信フレームの送受信タイミングを任意に変更する制御部を搭載する。なお、運転状況は、車両状態を示す情報に基づいて判断することが望ましい。因みに、車両状態を示す情報には、例えばアイドリングストップ、再起動、アクセルペダルの踏み込み量等がある。また、通信スケジュールとは、ＬＩＮ通信におけるフレーム通信の順序及び送受信のタイミングを示し、スケジュールテーブルにおいて規定される。また、運転状況に応じて通信スケジュールテーブルを任意に変更する制御部は、マスタ装置として動作するエンジン制御ユニットであることが望ましい。
【発明の効果】
【００１２】
運転状況の変化に応じて、スケジュールテーブルや通信フレームの送受信タイミングを変更できる。このため、運転状況に応じて優先度が高い通信フレームを優先して通信することができる。これにより、マスタ装置及びスレーブ装置を含めたシステム全体を、従来技術よりも早く運転状況の変化に追従させることができる。
【図面の簡単な説明】
【００１３】
【図１】形態例に係る車両制御装置の概略構成を説明する図である。
【図２】通信フレームの情報が保持されたテーブルの形態例を示す図である。
【図３】スケジュールテーブルの形態例を示す図である。
【図４】通信フレームのタイムチャート例を示す図である。
【図５】通信順序の変更を実現するフローチャート例を示す図である。
【図６】通信順序を変更した後のタイムチャート例を示す図である。
【図７】ＬＩＮ通信フレームの構成を説明する図である。
【図８】送受信タイミングの変更を実現するフローチャート例を示す図である。
【図９】通信フレーム１を優先したスケジュールテーブルの形態例を示す図である。
【図１０】通信フレーム１の優先によって変更されたタイムチャート例を示す図である。
【図１１】通信フレームの出力周期の変更を伴うタイムチャート例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面に基づいて、本発明の形態例を説明する。なお、形態例における説明や図面は、専ら発明を説明することを目的としたものであり、既知や周知の技術との組み合わせや置換も可能である。
【００１５】
（Ａ）システム構成
図１は、形態例に係る車両制御装置の内部構成を示す図である。形態例に係る車両制御装置は、マスタ装置となるＥＣＵ１０と、ＥＣＵ１０との間でデータを送受信するスレーブ装置としての複数の電子制御装置（第１スレーブ装置２０、第２スレーブ装置３０）で構成される。
【００１６】
ＥＣＵ１０と電子制御装置（第１スレーブ装置２０、第２スレーブ装置３０）とはＬＩＮに準拠した通信プロトコルにより、多重通信線１００を介して接続される。
【００１７】
ＥＣＵ１０は、第１スレーブ装置２０又は第２スレーブ装置３０に対してデータを送信し又はデータの送信を要求し、要求したデータを第１スレーブ装置２０又は第２スレーブ装置３０から受信し、第１スレーブ装置２０及び第２スレーブ装置３０を制御する機能も有している。第１スレーブ装置２０は例えばＩＳＧであり、第２スレーブ装置３０は例えば電圧変換器である。
【００１８】
図２に、通信フレームテーブルＴＢ１０の一例を示す。通信フレームテーブルＴＢ１０は、通信フレームのＩＤ、送受信の判別、通信フレームのデータ部の長さに関する情報を保持するテーブルである。通信相手はＩＤによって判別される。通信フレームテーブルはＲＯＭに格納されている。従って、プログラムは、これらの値を書き換えることができない。なお図２では、通信フレームのＩＤに対応するフレーム番号、フレーム種類との関係も示している。
【００１９】
図３に、スケジュールテーブルＴＢ２０の一例を示す。スケジュールテーブルは、通信フレームの番号とフレーム種類を通信する順番に配列したテーブルである。制御装置は、スケジュールテーブルを通信順序の第１要素から順番に参照することにより通信するフレーム番号を決定する。図３に示すスケジュールテーブルＴＢ２０は、ＥＣＵ１０が第１スレーブ装置２０及び第２スレーブ装置３０との通信に使用するスケジュールテーブルである。なお、スケジュールテーブルＴＢ２０はＲＡＭに格納されている。従って、これらの値はプログラムによる値の書き換えが可能である。
【００２０】
図４は、ＥＣＵ１０が、スケジュールテーブルＴＢ２０（図３）に従って動作する場合の通信フレームのタイムチャートである。図４の場合、ＥＣＵ１０は、第１スレーブ装置２０との間で通信フレーム「Ｆ＿Ｂ１」と「Ｆ＿Ｂ２」を通信し、続けて第２スレーブ装置３０との間で通信フレーム「Ｆ＿Ｃ１」〜「Ｆ＿Ｃ４」を通信する。
【００２１】
図１に示すように、この形態例に係るＥＣＵ１０は、記憶部１１と、処理部１２と、送受信部１３とを備えている。記憶部１１はＲＯＭとＲＡＭで構成され、ＲＯＭに通信フレームテーブルＴＢ１０を格納し、ＲＡＭにスケジュールテーブルＴＢ２０を格納している。
【００２２】
処理部１２は、記憶部１１と接続されるコンピュータシステムである。処理部１２は、スレーブ装置との間で信号を送受信するためのプログラムや一般的な処理プログラムをコンピュータを通じて実行する。なお、処理部１２は、処理に必要なプログラムも記憶する。この処理部１２が、ＲＡＭに格納されたスケジュールテーブルＴＢ２０との間で通信スケジュールの書き込みや読み出しを実行する。送受信部１３は、第１スレーブ装置２０と第２スレーブ装置３０との間で信号を送受信する通信装置で構成される。この形態例における送受信部１３は、ＬＩＮに準拠した通信プロトコルによりデータを送受信する。
【００２３】
（Ｂ）処理動作
（Ｂ−１）動作例１
以下では、運転状況に応じて通信順序を変更する手順を図５に基づいて説明する。なお、この通信順序の変更は、処理部１２が、図５に示す手順を記述したプログラムを実行することにより実現される。図５は、アイドリングストップ後のエンジン再始動時に、通信フレーム「Ｆ＿Ｂ１」を優先して送信する場合に使用する。
【００２４】
ステップＳ１０の実行時、ＥＣＵ１０（処理部１２）は、車両状態を示す情報の変化が検知されたか否かを判定する。この例の場合、ＥＣＵ１０は、ブレーキスイッチの解除信号を監視し、その変化の有無を通じて車両状態の変化を検知する。
【００２５】
運転状況の変化が検知された場合（ステップＳ１０で肯定結果が得られた場合）、ＥＣＵ１０はステップＳ１１に進む。一方、運転状況の変化が検知されなかった場合（ステップＳ１０で否定結果が得られた場合）、ＥＣＵ１０はステップＳ１１をスキップしてステップＳ１２に進む。
【００２６】
ステップＳ１１の実行時、ＥＣＵ１０は、ＲＡＭに格納されているスケジュールテーブルＴＢ２０に基づいて、次の通信フレームを「Ｆ＿Ｂ１」に変更する。すなわち、運転状況の変化に応じて通信スケジュールを変更する。ここでの変更は、事象発生時におけるスケジュールテーブルＴＢ２０（図３）上での現在の参照要素（通信順序）に対応するフレーム番号を、優先するフレーム番号（この例の場合は「１」）に変更することにより実現する。なお、後述するように、優先するフレーム番号の送信後に元の通信スケジュールに戻るために、ＥＣＵ１０は、変更前の参照要素（通信順序）のフレーム番号（この例の場合は「４」）をＲＡＭ等に記憶する。
【００２７】
ステップＳ１２の実行時、ＥＣＵ１０は、スケジュールテーブルＴＢ２０と参照要素（通信順序）に基づいて、次に通信する通信フレームを決定し、決定された通信フレームを送受信部１３を用いて送受信する。ステップＳ１２の通信が実行されると、ＥＣＵ１０は、ステップＳ１３に進む。
【００２８】
ステップＳ１３の実行時、ＥＣＵ１０は、ステップＳ１０で運転状況の変化を検知していたか否かを判定する。運転状況の変化が検知されていた場合（ステップＳ１３で肯定結果が得られた場合）、ＥＣＵ１０は、ステップＳ１４に進む。一方、運転状況の変化が検知されていなかった場合（ステップＳ１３で否定結果が得られた場合）、ＥＣＵ１０は、ステップＳ１４をスキップして処理を終了する。なお、ＥＣＵ１０は、ステップＳ１４をスキップする際、現在の参照要素（通信順序）を１つ進める。
【００２９】
ステップＳ１４の実行時、ＥＣＵ１０は、スケジュールテーブルＴＢ２０（図３）上での現在の参照要素（通信順序）に対応するフレーム番号を、保持しておいたステップＳ１１の変更前の状態に戻す。この形態例の場合、ＥＣＵ１０は、ステップＳ１１で記憶しておいた変更前の参照要素（通信順序）、すなわちフレーム番号「４」に戻す。以後、図５に示す処理が繰り返し実行される。
【００３０】
図６に、図４に示すタイムチャートにおいて、通信フレーム「Ｆ＿Ｃ１」を送信した後から通信フレーム「Ｆ＿Ｃ２」を送信するまでの間に運転状況が変化した場合に発生するタイムチャートを示す。すなわち、図６は、次に送受信する通信フレームを通信フレーム「Ｆ＿Ｃ２」に決定する前に、運転状況の変化を示すパラメータの参照により運転状況の変化が検知された場合に発生されるタイムチャートを示している。運転状況の変化が検知された場合、ＥＣＵ１０は、スケジュールテーブルＴＢ２０に対する読み出し位置を与える参照要素（通信順序）を、本来の通信フレーム番号「４」から優先する通信フレーム「Ｆ＿Ｂ１」に対応する通信フレーム番号「１」に書き換える。このため、図６では、先頭から４番目の位置で通信フレーム「Ｆ＿Ｂ１」が出力されている。この通信フレーム「Ｆ＿Ｂ１」の通信完了後、ＥＣＵ１０は、現在の参照要素を、保存しておいた変更前の通信フレーム番号「４」に戻す。このため、図６では、先頭から５番目の位置で通信フレーム「Ｆ＿Ｃ２」が出力され、以後、先頭から６番目の位置で通信フレーム「Ｆ＿Ｃ３」が出力され、先頭から７番目の位置で通信フレーム「Ｆ＿Ｃ４」が出力される。
【００３１】
このように、この動作例では、スケジュールテーブルＴＢ２０を書き換えずに、その読み出し位置を変更することにより、通信スケジュールを変更する。
【００３２】
（Ｂ−２）動作例２
以下では、運転状況に応じて送受信タイミングを変更する手順を図８に基づいて説明する。なお、この通信順序の変更は、処理部１２が、図８に示す手順を記述したプログラムの実行により実現される。図８は、アイドリングストップ後のエンジン再始動時に、通信フレーム「Ｆ＿Ｂ１」の送受信タイミング（周期）が短くなるように変更する場合に使用する。
【００３３】
ステップＳ２０の実行時、ＥＣＵ１０（処理部１２）は、車両状態を示す情の変化が検知されたか否かを判定する。この例の場合、ＥＣＵ１０は、ブレーキスイッチの解除信号を監視し、その変化の有無を通じて車両状態の変化を検知する。
【００３４】
運転状況の変化が検知された場合（ステップＳ２０で肯定結果が得られた場合）、ＥＣＵ１０はステップＳ２１に進む。一方、運転状況の変化が検知されなかった場合（ステップＳ２０で否定結果が得られた場合）、ＥＣＵ１０はステップＳ２１をスキップして処理を終了する。
【００３５】
ステップＳ２１の実行時、ＥＣＵ１０は、スケジュールテーブルＴＢ２０に記憶された通信順序自体を変更する。なお、動作例１の場合には、読み出し位置を与える参照要素（通信順序）の変更のみであり、スケジュールテーブルＴＢ２０自体はそのまま使用した。図９に、通信順序を変更した後のスケジュールテーブル例を示す。図９に示すスケジュールテーブルＴＢ３０は、通信フレーム「Ｆ＿Ｂ１」が他の通信フレームと交互に通信されるように、スケジュールテーブルＴＢ２０（図３）に対して要素を追加する場合の例を表している。図９の場合、「通信するフレーム番号」に「１」が交互に現われている。
【００３６】
図１０に、スケジュールテーブルＴＢ２０の先頭から３番目の通信フレーム「Ｆ＿Ｃ１」の送信後に運転状況の変化が検知された場合のタイムチャートを示す。図１０の場合、通信フレーム「Ｆ＿Ｃ１」の送信後であるので、以後、「Ｆ＿Ｂ１」→「Ｆ＿Ｃ２」→「Ｆ＿Ｂ１」→「Ｆ＿Ｃ３」→「Ｆ＿Ｂ１」→「Ｆ＿Ｃ４」→「Ｆ＿Ｂ１」→「Ｆ＿Ｂ２」→「Ｆ＿Ｂ１」…と通信フレームの通信が実行される。
【００３７】
ここで、通信フレームが１０ｍｓ毎に通信されるものとすると、この変更により、通信フレーム「Ｆ＿Ｂ１」の送受信タイミング（周期）は６０ｍｓから２０ｍｓへ変更される。なお、この送受信タイミングの変更は、例えば運転状況の変化が継続している間又は運転状況の変化の発生から一定期間の間だけ継続するようにプログラムを設定しても良い。
【００３８】
（Ｂ−３）動作例３
以下では、運転状況に応じて送受信タイミングを変更する他の動作例を説明する。前述した２つ動作例の場合には、運転状況の変化の検知時に、優先する通信フレームを強制的に出力又は出力回数を増加させる場合について説明した。この動作例では、運転状況の変化の検知時に、送受信タイミング（周期）を低下させる場合について説明する。なお、この通信順序の変更も、処理部１２によるプログラムの実行により実現される。
【００３９】
図１１に、この動作例に対応するタイムチャートの一例を示す。図１１は、スケジュールテーブルＴＢ２０（図３）に従う１０ｍｓ周期による通信フレームの送信において、運転状況の変化により１００ｍｓ周期に通信スケジュールを変更した場合のタイムチャートである。図に示すように、通信フレームの順序に変更はない。しかし、通信フレーム「Ｆ＿Ｃ１」の出力以後、各通信フレームの出力間隔が１０ｍｓ周期から１００ｍｓ周期に変更されている。この動作例の使用により、通信負荷や処理負荷を低減することができる。
【００４０】
（Ｃ）まとめ
前述したように、車両用ＬＩＮ通信装置の通信スケジュールを規定したスケジュールテーブルＴ２０を別のスケジュールテーブルＴ３０に変更することにより、優先すべき通信フレームについては当初のスケジュールテーブルＴ２０における通信順序によらず優先すべき通信フレームの通信を他の通信フレームの通信に優先することができる。
【００４１】
また、通信スケジュールの読み出し位置を指定する参照要素を変更する場合には、スケジュールテーブルＴ２０を用いながら、優先すべき通信フレームについては当初のスケジュールテーブルＴ２０における通信順序によらず優先すべき通信フレームの通信を他の通信フレームの通信に優先することができる。
【００４２】
なお、通信順序の変更は、運転状況の変化の検知に応じて実行することにより、運転状況の変化時に優先すべき通信フレームを速やかにスレーブ装置に送信することができる。これにより、運転状況の変化に対する車両の応答性を高めることができる。
【００４３】
また、マスタ装置としてのエンジン制御装置に通信スケジュールの変更機能を搭載することにより、運転状況の変化に応じてエンジン制御に関連する要求命令を速やかに実行することができる。
【符号の説明】
【００４４】
１０・・・ＥＣＵ、１１・・・記憶部、１２・・・処理部、１３・・・送受信部、２０・・・第１スレーブ装置、３０・・・第２スレーブ装置、１００・・・多重通信線、ＴＢ１０・・・通信フレームテーブル、ＴＢ２０・・・スケジュールテーブル、ＴＢ３０・・・スケジュールテーブル２。
【図１】
2010268066.tif 000003
【図２】
2010268066.tif 000004
【図３】
2010268066.tif 000005
【図４】
2010268066.tif 000006
【図５】
2010268066.tif 000007
【図６】
2010268066.tif 000008
【図７】
2010268066.tif 000009
【図８】
2010268066.tif 000010
【図９】
2010268066.tif 000011
【図１０】
2010268066.tif 000012
【図１１】
2010268066.tif 000013