(57)【要約】【課題】同じ識別情報を有する複数の電子制御装置が車載ＬＡＮに接続されていても、動的に識別情報を変更できる電子制御装置を提供すること。【解決手段】車載ＬＡＮを介して他の装置と接続される電子制御装置１００であって、送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフト１３と、予め設定されている自機の固有番号にて、前記通信ソフト１３に設定された前記識別情報を変更する固有番号適用手段２１と、を有する電子制御装置１００を提供する。【選択図】図２
2012114537.tif 000002
【特許請求の範囲】
【請求項１】
車載ＬＡＮを介して他の装置と接続される電子制御装置であって、
送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフトと、
予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、
を有する電子制御装置。
【請求項２】
予め設定されている自機の固有番号にて、前記通信ソフトに設定された送信メッセージの送信周期を変更する送信周期変更手段を有し、
前記通信ソフトは変更後の送信周期にて送信メッセージを送信する、
を有することを特徴とする請求項１記載の電子制御装置。
【請求項３】
前記他の装置から受信した受信メッセージに含まれる前記他の装置の前記識別情報と、自機の前記識別情報を比較して、自機の前記識別情報を前記他の装置が使用していない前記識別情報に変更する識別情報決定手段、
を有することを特徴とする請求項２記載の電子制御装置。
【請求項４】
前記固有番号適用手段は、前記通信ソフトに設定された前記識別情報に対し、前記固有番号の全部又は桁数の一部を用いた算術処理を施して前記通信ソフトに設定された前記識別情報を変更する、ことを特徴とする請求項１〜３いずれか１項記載の電子制御装置。
【請求項５】
前記固有番号適用手段は、前記固有番号の全体を用いて前記識別情報に対する算術処理を開始し、算術処理された前記識別情報が予め定められた前記識別情報の許容範囲に入らない場合、前記固有番号から取り出す桁数を徐々に減らして算術処理と前記許容範囲に入るか否かの判定を繰り返す、ことを特徴とする請求項４記載の電子制御装置。
【請求項６】
前記送信周期変更手段は、前記固有番号の上位桁又は下位桁から所定数の桁を取り出し、前記送信周期に加えること又は前記送信周期から減らすことで前記送信周期を変更し、
前記固有番号の全ての桁を取り出すまで、前記送信周期の変更を繰り返す、
ことを特徴とする請求項２又は３記載の電子制御装置。
【請求項７】
前記他の装置から受信した受信メッセージに含まれる前記他の装置の前記識別情報と、前記他の装置の固有番号を対応づけて記録する識別情報記録手段と、
受信メッセージを受信すべき前記他の装置の固有番号が予め登録された登録テーブルと、
前記登録テーブルに登録された前記他の装置の固有番号に基づき、受信メッセージを受信する前記他の装置の前記識別情報を前記通信ソフトに指示する識別情報管理手段と、
を有することを特徴とする請求項１〜６いずれか1項記載の電子制御装置。
【請求項８】
前記通信ソフトは、ＯＳＥＫ／ＶＤＸ−ＮＭの仕様に基づき、定期的に送信メッセージを送信する、ことを特徴とする請求項１〜７いずれか1項記載の電子制御装置。
【請求項９】
前記固有番号は、当該電子制御装置又は前記他の装置の品番又は型番である、ことを特徴とする請求項１〜８いずれか1項記載の電子制御装置。
【請求項１０】
車載ＬＡＮを介して複数の電子制御装置が接続された車両ネットワークシステムであって、
各電子制御装置が、送信メッセージに自機の識別情報を設定する、前記他の電子制御装置と共通の通信ソフトと、
予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、
を有する車両ネットワークシステム。
【請求項１１】
車載ＬＡＮを介して他の装置と共通の通信ソフトにより通信する電子制御装置の通信方法であって、
固有番号適用手段が、予め設定されている自機の固有番号にて、前記通信ソフトに設定されている識別情報を変更するステップと、
前記通信ソフトが、自機の識別情報を設定して送信メッセージを送信するステップと、を有する電子制御装置の通信方法。
【請求項１２】
車載ＬＡＮを介して他の装置と共通の通信ソフトにより通信する電子制御装置のＣＰＵに、
予め設定されている自機の固有番号を取得するステップと、
前記通信ソフトに設定されている識別情報を、前記固有番号にて変更するステップと、
前記通信ソフトに変更後の前記識別情報を設定するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両ネットワークシステムに接続される電子制御装置等に関し、特に、電子制御装置がＩＤに基づき通信する電子制御装置、車両ネットワークシステム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
車両の電子制御装置は各種の車載装置の動作を制御しているが、電子化の進行により数多くの電子制御装置が搭載されるようになっている。これらの電子制御装置を車載ＬＡＮにより接続し互いに情報を通信可能とすることでより高度な制御が実現されている。
【０００３】
各電子制御装置には、電子制御装置を識別するためのＩＤをＣＡＮコントローラに設定する通信ソフトが搭載される。通信ソフトの機能は複数の電子制御装置に共通の場合があるので、同じ通信ソフトを複数の電子制御装置に搭載することでコスト削減することが期待できる。しかしながら、通信ソフトが同じであることは通信ソフトが管理するＩＤも同じになることを意味する。このため以下のような不都合がある。
【０００４】
ＣＡＮプロトコルの場合、ＣＡＮコントローラは、ＣＡＮバスを使用する各電子制御装置の使用権をＣＡＮ-ＩＤで調停する。このため、通信ソフトが管理するＩＤが同じだと調停が困難になる。
【０００５】
図１はＣＡＮプロトコルのメッセージのフォーマットの一例を示す。ＣＡＮコントローラは、「Arbitration  Field」に通信ソフトが管理するＣＡＮ-ＩＤを設定し、使用権の調停にＣＳＭＡ／ＣＤ（Carrier  Sense  Multiple  Access／Collision  Detection）のアクセス制御を使用する。よって、ＣＡＮ-ＩＤが各電子制御装置で共通だとすると、同じタイミングでフレームを送信した複数のＣＡＮコントローラがＣＡＮバスの使用権を得てしまう。
【０００６】
しかし、その後のControl  Field以降で、あるＣＡＮコントローラがリセッシブを送信し、別のＣＡＮコントローラがドミナントを送信したタイミングで、どちらのＣＡＮコントローラも自身が送信したデータを受信できないことを検知してビットエラーを誤検出する。すると、ビットエラーを検出したＣＡＮコントローラは送信未完了が継続し、通信を停止するおそれがある。このため、従来は、ＩＤのために通信ソフトを電子制御装置毎に製造する必要があった。
【０００７】
複数のＥＣＵで通信ソフトを共通にする場合、車載ＬＡＮの各ＣＡＮコントローラに異なるＣＡＮ-ＩＤが設定される仕組みが必要になる。このような仕組みとして、テーブルを利用してＩＤを変換することが考えられる（例えば、特許文献１参照。）。特許文献１には、制御機器を増設用の通信路に増設した際、増設用の通信路と主通信路の間の中継装置が、予め記憶する主通信路で通信するための識別子と増設用通信路で通信するための識別子とを関連付けて登録した識別子変換テーブルを用いて、増設用の通信路から主通信路に中継するメッセージの識別子を変換する考案が開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−１９６９７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に開示された中継装置では、同じＣＡＮ-ＩＤの電子制御装置のメッセージの識別子は、変換後も同じ識別子になるため、結局、ＩＤの衝突が生じることになる。すなわち、単にテーブルを用意するだけでは、複数の同じＣＡＮ-ＩＤの電子制御装置の識別子を、異なる識別子に変えることは困難である。
【００１０】
本発明は、上記課題に鑑み、同じ識別情報を有する複数の電子制御装置が車載ＬＡＮに接続されていても、動的に識別情報を変更できる電子制御装置、車両ネットワークシステム、通信方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、車載ＬＡＮを介して他の装置と接続される電子制御装置であって、送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフトと、予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、を有する電子制御装置を提供する。
【発明の効果】
【００１２】
同じ識別情報を有する複数の電子制御装置が車載ＬＡＮに接続されていても、動的に識別情報を変更できる電子制御装置を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】ＣＡＮプロトコルのメッセージのフォーマットの一例を示す図である。
【図２】各電子制御装置が元のＩＤを重複しないＩＤに変更する手順を模式的に説明する図の一例である。
【図３】車載ＬＡＮの概略構成図の一例である。
【図４】スリープ制御又はウェイクアップ制御の手順を模式的に示す図の一例である。
【図５】本実施形態のプログラムについて説明する図の一例である。
【図６】初期ＩＤの決定手順を示すフローチャート図の一例である。
【図７】送信周期の変更手順を示すフローチャート図の一例である。
【図８】ＥＣＵ対応テーブルの一例を示す図である。
【図９】ＥＣＵがＩＤを決定する全体的な動作手順の一例を示す図である。
【図１０】ＩＤ及び送信周期の遷移を模式的に示す図の一例である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図２は、各電子制御装置が元のＩＤを重複しないＩＤに変更する手順を模式的に説明する図の一例である。
（１）電子制御装置（以下、ＥＣＵという）には、後に説明する共通の通信ソフトが搭載されているので、それぞれ同じＩＤを有する（図ではＥＣＵ_Ａ＝Ｎａ、ＥＣＵ_Ａ＝Ｎｂ）。このＩＤ（以下、元ＩＤという）はＣＡＮ-ＩＤとしてメッセージに設定される。このようにＩＤとＣＡＮ-ＩＤは同じものであるが、説明のため別の用語とした。
【００１５】
また、各ＥＣＵは、それぞれが重複しない固有番号を有している（図ではＥＣＵ_Ａ＝１２３４５、ＥＣＵ_Ａ＝１２３４６）。また、各ＥＣＵは送信するデータがある場合にメッセージを送信するだけでなく、後述する規格により定期的にメッセージを送信する。以下では、主に定期的に送信する場合を例に説明する。各ＥＣＵの通信ソフトは同じなので、送信周期はＥＣＵ_ＡとＥＣＵ_Ｂのいずれも一例として１００ミリ秒とする。
（２）車両の車載ＬＡＮに初めて電力が供給された場合（例えば、出荷後又はＥＣＵが初期化された後、初めてイグニッション・オンされた場合や初めてスタートボタンが押下された場合等）、各ＥＣＵは元ＩＤに固有番号の全部又は一部を算術加算する。以下、加算後のＩＤを初期ＩＤという。
【００１６】
初期ＩＤ  =  Na＋１２３４５（の一部）、初期ＩＤ  =  Nb＋１２３４６（の一部）
固有番号は重複しないので、元ＩＤに固有番号の全体を加えれば、必ず各ＥＣＵのＩＤを異ならせることができるが、ＣＡＮ-ＩＤのビット数は上限（多くの場合は11bit）を有しＣＡＮ-ＩＤの取り得る範囲に制約があるので、固有番号の一部を加算するとした。算術加算により、まず、各ＥＣＵで完全に一致していた元ＩＤが、互いに異なる初期ＩＤになるような処理が施されたことになる（以下、単に「分散させる」という）。
【００１７】
この状態で各ＥＣＵはメッセージを送信することができ、この段階で各ＥＣＵのＣＡＮ-ＩＤが完全に異なっている可能性もある。
（３）次に、各ＥＣＵは初期ＩＤが同じ他のＥＣＵが存在する可能性を考慮して、メッセージの送信周期を変更する。初期ＩＤが同じＥＣＵが同じタイミングでメッセージの送信を開始した場合、上述したようにＥＣＵによってはエラーを検知するが、ＥＣＵは、そのエラーがＩＤの重複によるものだということは判定できない。また、元の送信周期が同じなので、単に再送信しただけでは、メッセージが再度、衝突する可能性がある。したがって、初期ＩＤが同じ他のＥＣＵが存在する可能性のある状況では、各ＥＣＵはメッセージが正しく送受信されているか否かを確定できず、この結果、他のＥＣＵと初期ＩＤが重複しているかどうかも判定できない。
【００１８】
そこで、各ＥＣＵは、必ず他のＥＣＵと送信周期が異なるように送信周期を変更する。具体的には、「送信周期＝送信周期＋固有番号のｎ桁目」を新たな送信周期として、メッセージを送信する。これを固有番号の桁数分だけ繰り返すことにより、固有番号は重複しないので、初期ＩＤが同じＥＣＵが存在しても、各ＥＣＵは必ず１回以上、衝突なしにメッセージを送信できたことになる。
【００１９】
なお、各ＥＣＵは、他のＥＣＵと初期ＩＤが重複しているか否かを判定するため、元ＩＤを変えた後、送信周期を変え終わるまで、他のＥＣＵから受信したメッセージのＣＡＮ-ＩＤを不揮発メモリに記録する。
（４）各ＥＣＵは不揮発メモリに記憶した他のＥＣＵのＣＡＮ-ＩＤと自分の初期ＩＤを比較して、一致するＩＤがある場合、自分の初期ＩＤを使われていないＩＤに変更する。
【００２０】
以上の手順により、各ＥＣＵの通信ソフトが同じでも、数回のメッセージの送信で各ＥＣＵのＩＤを異ならせることができる。したがって、各ＥＣＵに同じ通信ソフトを搭載することができ、コストを低減することができる。
【００２１】
なお、各ＥＣＵは変更後のＩＤを記録しておくので、図示する作業は１回だけ行えばよい。したがって、各ＥＣＵがＩＤを設定するまでユーザに待ち時間が発生するなどの不都合も生じない。
【００２２】
〔構成〕
図３は、車載ＬＡＮ２００の概略構成図の一例を示す。各ＥＣＵ１００は、各ＥＣＵ独自の制御のため異なる構造やアプリ１１（区別する場合、アプリＡ，Ｂという）を搭載しているが、ＩＤの変更に関する各ＥＣＵの構成は同じである。図３では、ＥＣＵ_ＡがアプリＡを有し、ＥＣＵ_ＢがアプリＢを有する点で両者の構成が異なっているだけである。すなわち、ＥＣＵ_ＡとＥＣＵ_Ｂのいずれも同じ通信ソフト１３（以下、区別する場合、通信ソフトＡ、Ｂという）を有している。
【００２３】
ＥＣＵ１００は、ＣＰＵ、ＲＡＭ，ＥＥＰＲＯＭ、ＮＶＲＡＭ、Ｉ／Ｏ等を備えたマイコンである。また、マイコンは、ＣＡＮ通信のＣＡＮコントローラ１５、通信ソフト１３及び通信ソフト１３に組み込まれたプログラム１４、を有する。また、図では、ＮＶＲＡＭをメモリ１２で表した。このメモリ１２には、他のＥＣＵ１００のＩＤが記憶される。
【００２４】
アプリＡは、ＥＣＵ_Ａが必要な制御や処理を行うためのアプリケーションソフトである。アプリＢについても同様である。アプリＡ、アプリＢは、ＥＣＵ_Ａ、ＥＣＵ_Ｂに接続されたセンサから信号を取得し、必要な演算や判定を行い、アクチュエータやスイッチを制御する。アプリＡ，Ｂは、必要であれば、センサの信号、演算結果を他のＥＣＵ１００にメッセージとして提供する。
【００２５】
ＥＣＵ_ＡがＨＶ（ハイブリッド）−ＥＣＵの場合は、アプリＡは、アクセルペダル開度、ブレーキペダルの踏み込み量、シフトポジション、モータジェネレータを流れる電流値、モータジェネレータの回転速度に基づき、モータジェネレータＭＧ１，ＭＧ２の３相コイルに流す電流を決定し、決定した電流値に応じた駆動信号をインバータへ出力する等の処理を行う。
【００２６】
ＥＣＵ_ＢがブレーキＥＣＵの場合、アプリＢは、車速センサが検出する車輪の回転速度からスリップ率を算出し、各輪のスリップ率に応じてＡＳＢやＴＲＣなどの処理を行う。この他、車両にはエンジンＥＣＵ、ボディＥＣＵ、ナビＥＣＵ等が搭載されるが、ＥＣＵ_Ａ、ＥＣＵ_Ｂは１つの車載ＬＡＮ２００に接続されたＥＣＵであればよい。なお、１つの車載ＬＡＮ２００とは、中継装置（ゲートウェイ）を含めメッセージの送受信が可能な範囲や中継装置を超えない範囲である。車載ＬＡＮに中継装置を含めるか否かは、通信ソフト１３の共通性やメッセージの衝突の可能性を考慮して決定する。
【００２７】
アプリＡはＥＣＵ_Ａの固有番号を保持し、アプリＢはＥＣＵ_Ｂの固有番号を保持している。具体的には、アプリＡとアプリＢのコードに固有番号が記述されている。アプリＡ，Ｂのコードでなくメモリ１２に記憶しておくこともできる。固有番号を通信ソフト１３以外に記憶させることで、各ＥＣＵ１００で同じ通信ソフト１３を使用できる。
【００２８】
固有番号は、例えば、ＥＣＵ１００の品番、型番など、各ＥＣＵ１００で重複しない番号であればよい。品番や型番は、そのＥＣＵ１００がＨＶ−ＥＣＵであることやブレーキＥＣＵであることを特定する番号なので、同種のＥＣＵ１００は１つの車載ＬＡＮ２００に１つしか搭載されないことを前提とすると、各ＥＣＵ１００の固有番号が異なっているとみなすことができる。
【００２９】
この他、例えば、各ＥＣＵ１００に重複しない識別番号を付与する特定のＥＣＵが車載ＬＡＮ２００に接続されている場合、この特定のＥＣＵが各ＥＣＵ１００に割り当てる識別番号を固有番号とすることもできる。
【００３０】
通信ソフト１３は、アプリＡ又はアプリＢが送信要求したデータをＣＡＮコントローラ１５のバッファに設定するプログラムである。ＣＡＮプロトコルでは、図1のフォーマットのメッセージを送信するので、通信ソフト１３は、アプリＡ又はアプリＢからデータの送信要求を受け付けると、「Start  of  Frame」に1 ビットのドミナントを、ＣＡＮ-ＩＤに上記のようにして決定したＩＤを、「Control  Filed」にデータフィールド内のデータのバイト数を、「Data
Field」にデータを、「CRC  Field」にCRC符号を、「ACK」に１ビットのリセッシブ（送信の場合）を、「End  of  Frame」 に7 ビットのリセッシブを、それぞれ設定する。送信ソフト１３がこのようなメッセージをＣＡＮコントローラ１５の送信バッファに記憶すると、ＣＡＮコントローラ１５がトランシーバ１６を介してＣＡＮバスから送信を開始する。
【００３１】
また、通信ソフト１３は、ＯＳＥＫ／ＶＤＸ（Offene  Systeme  und  deren  schnittstellen  fur  die  Elektronik  im  Kraftfahrzeug／Vehicle  Distributed  eX  ecutive）仕様のＯＳＥＫ／ＶＤＸ―ＮＭ（Network  Management）の規定に基づく通信を行うが、この通信については後述する。
【００３２】
ＣＡＮコントローラ１５は、ＣＡＮの通信プロトコルに従って、送信バッファのメッセージをシリアルの送信信号に変換してトランシーバ１６に出力する。すなわち、メッセージが“０”のビットには論理レベルがLowの電圧を、メッセージが“１”のビットには論理レベルがHighの電圧を出力する。
【００３３】
トランシーバ１６はＣＡＮコントローラ１５から取得した論理レベルの送信信号を対応する差動電圧に変換してＣＡＮバスに送信する。ＣＡＮバスは各ＥＣＵ１００に接続されているので、各ＥＣＵ１００がメッセージを取得することができる。送信時、ＣＡＮコントローラ１５はCSMA/CDに基づきメッセージの衝突を検出している。
【００３４】
データの受信時、トランシーバ１６はＣＡＮバスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号を、ＣＡＮコントローラ１５に出力する。ＣＡＮコントローラ１５の受信用の端子はコンパレータを有しており、所定の閾値電圧とトランシーバ１６からの受信信号とを比較して“１”、“０”のデジタルデータを生成して受信バッファに記憶する。
【００３５】
ＣＡＮプロトコルでは、各ＥＣＵ１００が同じ１つのメッセージを受信してしまうので、通信ソフト１３又はアプリ１１がＩＤに基づき受信すべきメッセージを取捨している（以下、通信ソフト１３が取捨しているとする）。各ＥＣＵ１００にとって必要なメッセージはＣＡＮ-ＩＤによりＥＣＵ毎に定められている。
【００３６】
ところが、本実施形態では元ＩＤが各ＥＣＵ１００で同じであり、その後、変更されるため、予め通信ソフト１３に受信すべきＣＡＮ-ＩＤを設定しておくことが困難になっている。このため、本実施形態では、図２の処理にてＩＤを決定する際、各ＥＣＵ１００が他のＥＣＵ１００の固有番号とＩＤを特定しておき、変更後のＩＤに基づきメッセージを取捨できるようにする。この処理の詳細は後述する。
【００３７】
プログラム１４は、図２にて説明した処理（ソフト的処理）を実行する。プログラム１４も各ＥＣＵ１００に共通である。図ではプログラム１４が通信ソフト１３に含まれるように記載したが、プログラム１４はアプリ１１に含まれる形でＥＣＵ１００に搭載することもできるし、通信ソフト１３及びアプリ１１に独立に搭載することもできる。プログラム１４の機能については後述する。
【００３８】
〔ＯＳＥＫ−ＮＭ〕
ＯＳＥＫ−ＮＭでは、１つの車載ＬＡＮ２００に接続された各ＥＣＵ１００が、自ＥＣＵ１００のスリープ可否を判別して、そのスリープ可否を示すＮＭ（Network  Management）メッセージを定期的にネットワークバスへ送信する。通信ソフト１３はこのＯＳＥＫ−ＮＭに基づく通信処理も行う。なお、ＮＭメッセージはＣＡＮのメッセージの一表現に過ぎず、フォーマットや送信手順はＣＡＮプロトコルに従うが、周期的に送信されるなどの特徴があるのでＯＳＥＫ−ＮＭに基づくメッセージをＮＭメッセージという。
【００３９】
ＯＳＥＫ−ＮＭには各ＥＣＵ１００の動作モードとしてスリープモードとウェイクアップモード等が定義されている。スリープモードは、例えば、ＣＰＵに供給するクロックを最小限に小さくしたり、電力が供給されるチップを最小限にするモードである。ＥＣＵ１００は、車両のＩＧ（イグニション）＝ＯＦＦ時において、ＩＧ＝ＯＮ、ドア開、リモート制御用の電波信号受信、他のＥＣＵ１００からのバスエッジ受信などのイベントが長期間検知されない場合、スリープモードになる。また、スリープモードにおいてイベント発生が検知された場合、スリープモードを解除して、電源供給を受けて初期化を行い起動しウェイクアップモードになる。
【００４０】
１つの車載ＬＡＮ２００では各ＥＣＵ１００が通信することで処理を実行したり、正常／異常判定を行ったりするので、ＯＳＥＫ−ＮＭでは各ＥＣＵ１００が協調してスリープ制御及びウェイクアップ制御を行うようになっている。
図４は、スリープ制御又はウェイクアップ制御の手順を模式的に示す図の一例である。各ＥＣＵ１００は、スリープが可能か否かの判定結果を定期的にＮＭメッセージに記述して送信する。図示するように、ＥＣＵ_Ａ〜ＥＣＵ_Ｃは、順番にＮＭメッセージを送信する。この順番は予め定められており、ＥＣＵ_ＡはＥＣＵ_Ｂに、ＥＣＵ_ＢはＥＣＵ_Ｃに、ＥＣＵ_ＣはＥＣＵ_Ａに、ＮＭメッセージを送信する。そしてこの送信周期が上記のように各ＥＣＵ１００に共通に定められている。
【００４１】
したがって、各ＥＣＵ１００は、最後にＮＭメッセージを送信した時から送信周期が経過するとスリープが可能か否かの判定を行い、スリープ可否を示すＮＭメッセージを送信する。送信周期が各ＥＣＵ１００に共通の場合、ＮＭメッセージを1回受信する度に、ＮＭメッセージを1回送信することになる。各ＥＣＵ１００の送信周期が異なると、ＮＭメッセージの受信と送信の頻度は一致しないが、各ＥＣＵ１００は、他のＥＣＵ１００からのＮＭメッセージの受信のタイミングに関係なく、送信周期に従ってＮＭメッセージを送信すればよい。
【００４２】
各ＥＣＵ１００は、ＮＭメッセージを受信すると、各ＥＣＵ毎にスリープ可否か否かを各ＥＣＵ１００に対応したフラグのON/OFFにて記録する。そして、全てのＥＣＵ１００がスリープ可になると、各ＥＣＵ１００はスリープモードへ移行する処理を開始する。
【００４３】
スリープモードになるまで各ＥＣＵ１００は周期的にＮＭメッセージを送信するはずなので、各ＥＣＵ１００はＮＭメッセージの受信有無により他のＥＣＵ１００の正常／異常判定を行うことができる。
【００４４】
また、スリープモードにおいていずれかのＥＣＵ１００がイベントを検出すると、まずそのＥＣＵ１００が起動する。起動したＥＣＵ１００はウェイクアップ要求を含むＮＭメッセージを予め定められた他のＥＣＵ１００に送信する。ウェイクアップ要求を受信したＥＣＵ１００が起動すると、ウェイクアップ要求を含むＮＭメッセージを予め定められた他のＥＣＵ１００に送信するので、車載ＬＡＮ２００の各ＥＣＵ１００が起動することができる。
【００４５】
〔プログラム〕
図５を用いて、本実施形態のプログラム１４について説明する。通信ソフト１３はＣＰＵがプログラム１４を実行することで得られる、ＩＤ算出部２１、送信周期変更部２２、ＩＤ管理部２４、ＩＤ決定部２３及びＩＤ記録部２６を有する。また、ＥＣＵ対応テーブル２５は、プログラム１４に定数として記述されている。
【００４６】
ＩＤ算出部２１は、通信ソフト１３から元ＩＤを、アプリ１１から固有番号をそれぞれ取得し、元ＩＤに固有番号の一部を加算して初期ＩＤを決定する。ここで、元ＩＤは、ＣＡＮプロトコルのフォーマットの「Arbitration  Filed」の桁数の制約と、車両メーカの仕様上の制約を受ける。「Arbitration  Filed」は例えば１１ビットであるので、この上限を超えることはできない。また、車両メーカは、ＣＡＮ-ＩＤがある範囲に入るように定めることでＥＣＵ１００の管理を容易にしている。
【００４７】
このため、ＩＤ算出部２１は仕様上の範囲に入るように、通信ソフト１３から取得した元ＩＤに固有番号の一部を加算する。なお、通信ソフト１３の元ＩＤは例えば、車両メーカのＣＡＮ-ＩＤの仕様上の範囲の中央値又は中央値に近くなるように定められている。
【００４８】
図６は、初期ＩＤの決定手順を示すフローチャート図の一例である。まず、ＩＤ算出部２１は、通信ソフト１３から元ＩＤを、アプリ１１から固有番号をそれぞれ取得する（Ｓ１０）。
【００４９】
ＩＤ算出部２１は、固有番号の全体の桁数ｎを特定する（Ｓ２０）。桁数ｎは例えば十進数表記の桁数である。また、固有番号に「−（ハイフン）」が含まれている場合、ハイフンを取り除いて桁数ｎを求める。また、固有番号にアルファベットが含まれている場合、アルファベットをアルファベットに応じて予め定められた別の数字（例えばアルファベット順の下一桁）に置き換える。または、アルファベットを無視してもよい。
【００５０】
次に、ＩＤ算出部２１は、元ＩＤに固有番号の上位ｎ桁を加える（Ｓ３０）。最初のｎは全桁数なので、1度目の加算では固有番号の全体が元ＩＤに加算され、各ＥＣＵ１００のＩＤを必ず異ならせることができる。
【００５１】
そして、ＩＤ算出部２１は、固有番号の加算後のＩＤが仕様上の範囲に入っているか否かを判定する（Ｓ４０）。入っている場合は（Ｓ４０のＹｅｓ）、ＩＤ算出部２１は現在のＩＤを初期ＩＤとして決定する（Ｓ５０）。
【００５２】
固有番号の加算後のＩＤが仕様上の範囲に入っていない場合（Ｓ４０のＮｏ）、ＩＤ算出部２１はｎ桁を１つ減らす（Ｓ６０）。この後、処理はステップＳ３０に戻るので、ＩＤ算出部２１は、ＩＤに固有番号の上位ｎ桁を加えることになる。こうすることで、固有番号から抽出する桁数を少なくできるので、いずれは必ずＩＤが仕様上の範囲に入るようになる。
【００５３】
初期ＩＤが決定するとＩＤ算出部２１は通信ソフト１３に初期ＩＤを設定して処理を終了する（Ｓ７０）。
【００５４】
なお、ステップＳ３０でＩＤ算出部２１は上位ｎ桁を抽出するが、下位ｎ桁でもよいし、中央の桁からｎ桁でもよい。また、ステップＳ３０では元ＩＤに固有番号の上位ｎ桁を加えているが、元ＩＤから固有番号の上位ｎ桁を減算してもよい。
【００５５】
図５に戻り、送信周期変更部２２は、通信ソフト１３から送信周期を、アプリＡから固有番号をそれぞれ取得し、送信周期に、固有番号のｎ桁目を加算して新たな送信周期とする。ｎ桁の全てを順番に加算することで、必ず1回は他のＥＣＵ１００と異なる送信周期で送信することができる。
【００５６】
図７は、送信周期の変更手順を示すフローチャート図の一例である。まず、送信周期変更部２２は、通信ソフト１３から送信周期を、アプリＡから固有番号をそれぞれ取得する（Ｓ１１０）。
【００５７】
次に、送信周期変更部２２は、固有番号の全体の桁数ｎを特定する（Ｓ１２０）。桁数ｎの決定方法は上記のとおりである。
【００５８】
次に、送信周期変更部２２は、送信周期に固有番号のｎ桁目を加える（Ｓ１３０）。ｎ桁は最下位桁から数えても、最上位桁から数えてもよい。そして、通信ソフト１３に変更後の送信周期を設定する（Ｓ１４０）。これにより、通信ソフト１３は、変更後の送信周期で1回以上、ＮＭメッセージを送信することができる。
【００５９】
送信周期変更部２２は、通信ソフト１３がＮＭメッセージを送信するまで待機し（Ｓ１５０）、送信すると、送信周期変更部２２はｎを１つ減らす（Ｓ１６０）。そして、ｎが“０”になったか否かを判定する（Ｓ１７０）。
【００６０】
ｎが“０”になった場合（Ｓ１７０のＹｅｓ）、ｎ桁の全てを送信周期に加算したことになるので、送信周期変更部２２は処理を終了する。ｎが“０”になっていない場合（Ｓ１７０のＮｏ）、処理はステップＳ１３０に戻り、送信周期に固有番号のｎ桁目を加える処理を行う。
【００６１】
したがって、ｎ桁の全てを加算したことで、通信ソフトＡは他のＥＣＵ１００と異なる送信周期で送信することができた。なお、図７の処理の後、または、図７の処理に変えて、固有番号の２桁以上を送信周期に加算してもよい。すなわち、上位又は下位から２桁ずつを取り出し送信周期に加算する。同様に、３桁、４桁…を送信周期に加算することもできる。しかし、あまり大きい数値を加算すると送信周期が長くなり、ＩＤの決定までに時間がかかることになるので、２桁まで加算することが好適となる。
【００６２】
また、固有番号のｎ桁目を送信周期に加算するのでなく、減算してもよい。元の送信周期が１００ミリ秒だとすると固有番号の1桁を送信周期から減算しても、送信周期が負値となることはなく、ＩＤの決定までの時間を短縮できる。
【００６３】
図５に戻りＩＤ記録部２６は、図６，７の処理の間に受信したＮＭメッセージに基づきＣＡＮ-ＩＤを記録する。例えば、メモリ１２には、受信したＣＡＮ-ＩＤとして「１２３，４５７，７８９…」のように記録される。
【００６４】
ＩＤ決定部２３は、ＩＤ算出部２１が決定した初期ＩＤが、ＩＤ記録部２６が記録した他のＥＣＵ１００のＣＡＮ-ＩＤに一致するものがあるか否かを判定し、他のＥＣＵ１００のＣＡＮ-ＩＤに一致するものがある場合、使われていないＣＡＮ-ＩＤを最終的なＩＤに決定する。ＩＤの決定方法には、使われている最も大きいＣＡＮ-ＩＤに所定値を加える方法、使われている最も小さいＣＡＮ-ＩＤから所定値を減算する方法、自ＥＣＵの初期ＩＤと一致したＣＡＮ-ＩＤにランダムな値を加える／減算する方法、等がある。なお、同じＣＡＮ-ＩＤを有する２つのＥＣＵは同時にメッセージを送信できないので（いずれも通信を停止する）、２つのＥＣＵが同時にＣＡＮ-ＩＤが重複すると判定することはない。したがって、先に重複を検出したＥＣＵのＩＤ決定部２３がＩＤを変更すればよい。
【００６５】
各ＥＣＵのＩＤ決定部２３がこのようにしてＩＤを交換することで、各ＥＣＵのＩＤが重複しないＩＤとなるが、これだけでは各ＩＤがどのＥＣＵのＩＤかを各ＥＣＵが特定できない。そこで、ＩＤ管理部２４は、最終的に決定したＩＤと自ＥＣＵの固有番号を他のＥＣＵ１００に通知する。通知のタイミングは図７の手順の後でもよいし、図６，７の手順と並行に通知することもできる。すなわち、ＯＳＥＫ−ＮＭの規格上、ＮＭメッセージにスリープ可否だけでなく固有番号を含めることができれば、図６，７の手順と並行に通知すればよい。
【００６６】
ＩＤと固有番号の対応を受信した他のＥＣＵ１００のＩＤ管理部２４は、下記のように他のＥＣＵ１００のＩＤと固有番号を記録する。なお、ＥＣＵ_Ａ〜Ｄのような名称は実際には送受信されない。
ＥＣＵ_Ａ（７８２１−１２３）：１２３  
ＥＣＵ_Ｂ（８６１０−１２３）：４５６  
ＥＣＵ_Ｃ（８６１５−１２３）：７８９  
ＥＣＵ_Ｄ（８８１０−１２３）：９８７  
こうすることで、ＩＤ管理部２４は、各ＥＣＵとＩＤの対応を特定することができる。このＩＤは車載後に決まったので、ＩＤとＥＣＵ１００の対応付けを利用して、ＩＤ管理部２４は通信ソフト１３が受信すべきメッセージを特定する。このため、本実施形態ではＥＣＵ対応テーブル２５を利用する。  
図８は、ＥＣＵ対応テーブル２５の一例を示す図である。ＥＣＵ対応テーブル２５には、左側のＥＣＵ１００が受信すべきメッセージの送信元のＥＣＵ１００が「○」で登録されている。ＥＣＵ対応テーブル２５のＥＣＵ１００は固有番号にて記述されているか、又は、少なくとも固有番号を含んでいる。図８によればＥＣＵ_ＡはＥＣＵ_ＢとＥＣＵ_Ｄのメッセージを受信する必要があり、ＥＣＵ_ＢはＥＣＵ_ＡとＥＣＵ_ＣとＥＣＵ_Ｄのメッセージを受信する必要があり、ＥＣＵ_ＣはＥＣＵ_ＡとＥＣＵ_Ｂのメッセージを受信する必要があり、ＥＣＵ_ＤはＥＣＵ_Ｃのメッセージを受信する必要がある。なお、各ＥＣＵ１００のＩＤ管理部２４は、自ＥＣＵ１００がどのＥＣＵ１００であるかは、アプリ１１から取得する固有番号により判定できる。
【００６７】
ＩＤ管理部２４は、自ＥＣＵの固有番号に基づきＥＣＵ対応テーブル２５から、メッセージを受信すべきＥＣＵ１００の固有番号を特定する。そして、ＩＤ管理部２４が記録した他のＥＣＵ１００のＩＤと固有番号の対応から、メッセージを受信すべきＥＣＵ１００のＩＤを特定し通信ソフト１３に通知する。例えば、ＥＣＵ_ＡのＩＤ管理部２４なら、ＥＣＵ_ＢとＥＣＵ_Ｄを意味するＩＤ４５６と７８９を通信ソフト１３に通知する。
【００６８】
なお、ＥＣＵ対応テーブル２５を有さないＥＣＵは、ＩＤの上位数桁を固定し、その範囲に含まれるＩＤを持つＥＣＵであれば受信する、という規則で受信すべきメッセージを特定することができる。よって、ＥＣＵ対応テーブル２５は必ずしも必須ではない。
【００６９】
〔全体の動作手順〕
図９は、ＥＣＵ１００がＩＤを決定する全体的な動作手順の一例を、図１０はＩＤ及び送信周期の遷移を模式的に示す図の一例である。
【００７０】
ＥＣＵ１００が起動すると、通信ソフト１３は重複しないＩＤが決定されているか否かをフラグなどで判定し、決定されていない場合、プログラム１４にＩＤの決定を要求する。図９の手順は、例えばこのようにして開始される。なお、以下ではＮＭメッセージにＥＣＵの固有番号を含めるとした。
【００７１】
まず、ＩＤ算出部２１は、図６の手順を実行しＩＤに固有番号を加算して初期ＩＤを加算する（Ｓ３１０）。通信ソフトＡは初期ＩＤを用いて、例えばＮＭメッセージの周期的な送信を開始する（Ｓ３２０）。他のＥＣＵ１００も同様に送信を開始するので、ＩＤ記録部２６は、他のＥＣＵ１００から受信したメッセージのＩＤとメッセージに含まれる固有番号を記録する。
【００７２】
次に、送信周期変更部２２は、図７の手順を実行して、送信周期に固有番号のｎ桁目を加算してメッセージを送信する（Ｓ３３０）。
【００７３】
通信ソフトＡは、他のＥＣＵ１００から送信されたメッセージを受信する（Ｓ３４０）。ＩＤ記録部２６は、他のＥＣＵ１００から受信したメッセージのＩＤとメッセージに含まれる固有番号を記録する。
【００７４】
次に、ＩＤ決定部２３は、自ＥＣＵの初期ＩＤが他のＥＣＵのＩＤに一致するか否かを判定する（Ｓ３５０）。一致する場合（Ｓ３５０のＹｅｓ）、ＩＤ決定部２３は、初期ＩＤを使われていないＩＤに変更する（Ｓ３６０）。
【００７５】
この後、処理はステップ３３０に戻り、必ず重ならない送信周期でＮＭメッセージが送信されるまで継続する。ＩＤ記録部２６はその間に記録したＩＤと固有番号の対応をＩＤ管理部２４に通知し、ＩＤ管理部２４はＥＣＵ対応テーブル２５に基づき通信ソフト１３に、受信すべきＩＤを通知する。
【００７６】
図１０を用いて説明する。図１０では、ＥＣＵ_Ａの固有番号が7821-123、ＥＣＵ_Ｂの固有番号が8610-123、ＥＣＵ_Ｃの固有番号が8615-123、ＥＣＵ_Ｄの固有番号が8810-123である。ＥＣＵ_Ｂ〜Ｄの元ＩＤは４１０であり、送信周期は１００ミリ秒である。
【００７７】
ＥＣＵ_Ａには通信ソフトＡが搭載されているが、ＥＣＵ_Ｂ〜Ｄには通信ソフトＢが搭載されている。通信ソフト１３が異なるとＩＤも異なるので、図１０ではＥＣＵ_Ｂ〜ＤのＩＤを変更すればよい。実際には、ＥＣＵ_Ｂ〜Ｄは同じ車載ＬＡＮ２００に接続されているＥＣＵ_Ａからもメッセージを受信しているので、ＥＣＵ_ＡのＩＤと重複しないように自ＥＣＵのＩＤを決定する。
【００７８】
図１０の1回目の送信が、ステップＳ３２０の送信に対応する。初期ＩＤを決定するため、各ＥＣＵは固有番号の上位２桁を元ＩＤに加算するとする。よって、ＥＣＵ_Ｂは４１０＋８６＝４９６を、ＥＣＵ_Ｃは４１０＋８６＝４９６を、ＥＣＵ_Ｄは４１０＋８８＝４９８を、それぞれ初期ＩＤとする。ＥＣＵ_Ｂ〜Ｄは少なくとも1回以上、ＮＭメッセージを送信する。この時の送信周期は１００ミリ秒である。
【００７９】
図１０の２、３…回目の送信が、Ｓ３３０の送信に対応する。例えば、固有番号の上位から３桁目を送信周期に加算した場合、ＥＣＵ_Ｂの固有番号8610-123の上位から３桁目は「１」なので、ＥＣＵ_Ｂの送信周期は１００＋１＝１０１ミリ秒となる。ＥＣＵ_Ｃの固有番号8615-123の上位から３桁目は「１」なので、ＥＣＵ_Ｃの送信周期は１００＋１＝１０１ミリ秒となる。ＥＣＵ_Ｄの固有番号8610-123の上位から３桁目は「１」なので、ＥＣＵ_Ｄの送信周期は１００＋１＝１０１ミリ秒となる。ＥＣＵ_Ｂ〜Ｄは少なくとも1回以上、この送信周期でＮＭメッセージを送信する。
【００８０】
次の送信タイミングでは、固有番号の上位から４桁目を送信周期に加算する。このため、ＥＣＵ_Ｂの送信周期は１０１＋０＝１０１ミリ秒となる。ＥＣＵ_Ｃの送信周期は１０１＋５＝１０６ミリ秒となる。ＥＣＵ_Ｄの送信周期は１０１＋０＝１０１ミリ秒となる。ＥＣＵ_Ｂ〜Ｄは少なくとも１回以上、この送信周期でＮＭメッセージを送信する。固有番号に基づき送信周期を変えてＮＭメッセージの送信を繰り返すことで、少なくとも1回はＥＣＵ_Ｂ〜Ｄは他のＥＣＵのＮＭメッセージを衝突なしに受信することができる。
【００８１】
すると、例えば、ＥＣＵ_Ｃは、ＥＣＵ_ＢとＩＤが４９６で一致していることを検知できるので、初期ＩＤ＝４９６を、ＥＣＵ_ＢやＥＣＵ_Ｄが使用していないＩＤに変更する。例えば、ＥＣＵ_Ｂの初期ＩＤ＝４９６に所定値３を加えて、初期ＩＤをＩＤ＝４９９に変更する。
【００８２】
この後、各ＥＣＵは送信周期を元の１００ミリ秒に戻してもよい。送信周期を変更したのは、衝突なしに各ＥＣＵのＩＤを受信するためだから、重複しないＩＤが決定された後は送信周期が共通でもよいからである。また、送信周期を共通にすることで、ＯＳＥＫ／ＶＤＸ―ＮＭの仕様が送信周期が共通であることを要求する場合に、その要求を満たすことができる。
【００８３】
以上説明したように、本実施形態のＥＣＵ１００は、車載ＬＡＮ２００上で重複しないＩＤを自動的に決定するので、各ＥＣＵ１００が同じ通信ソフトＡを搭載することができ、コスト低減が可能になる。ＩＤの変更に固有番号を利用するので、他のＥＣＵ１００と重複しないＩＤを見いだしやすい。また、送信周期の変更に固有番号を利用するので、他のＥＣＵ１００と重複しない送信周期に設定でき、ＩＤが重複しているか否かを判定することができる。そして、重複している場合には重複しないＩＤに決定することができる。
【符号の説明】
【００８４】
１１    アプリ
１２    メモリ
１３    通信ソフト
１４    プログラム
１５    ＣＡＮコントローラ
１６    トランシーバ
２１    ＩＤ算出部
２２    送信周期変更部
２３    ＩＤ決定部
２６    ＩＤ記録部
１００  ＥＣＵ
２００  車載ＬＡＮ
【図１】
2012114537.tif 000003
【図２】
2012114537.tif 000004
【図３】
2012114537.tif 000005
【図４】
2012114537.tif 000006
【図５】
2012114537.tif 000007
【図６】
2012114537.tif 000008
【図７】
2012114537.tif 000009
【図８】
2012114537.tif 000010
【図９】
2012114537.tif 000011
【図１０】
2012114537.tif 000012