JP2010280356A - 車載システム、負荷分散方法 - Google Patents

Abstract

【課題】処理能力に余裕がある電子制御ユニットに効率的に負荷分散できる車載システム及び負荷分散方法を提供すること。
【解決手段】車載ＬＡＮ２６を介して接続された複数の電子制御ユニットを有する車載システム１００において、各電子制御ユニットは、当該電子制御ユニットの余剰処理能力を測定する、ハードウェアで実装された測定手段２１，２２と、余剰処理能力を他の電子制御ユニットに通知する通知手段１５、３１と、他の電子制御ユニットから通知された余剰処理能力を各電子制御ユニットに対応づけて登録したテーブル２５と、他の電子制御ユニットの余剰処理能力に基づき、他の電子制御ユニットに当該電子制御ユニットの負荷を分散する負荷分散手段３４と、を有する、ことを特徴とする。
【選択図】図１

Description

本発明は、複数の電子制御ユニットが車載ＬＡＮで接続された車載システム及び負荷分散方法に関し、特に、電子制御ユニット間で負荷の分散が可能な車載システム及び負荷分散方法に関する。

車両に搭載された複数の電子制御ユニットは互いに車載ＬＡＮにより接続され、センサの検出信号や他の電子制御ユニットが処理したデータを共有することで、各電子制御ユニットに接続されたアクチューエータや車載装置の協調制御を実現している。そして、車載ＬＡＮに接続されていることを利用して、その電子制御ユニットの本来の処理を他の電子制御ユニットに依頼することで、負荷を分散することが考えられている。

例えば、マルチコアＣＰＵではＣＰＵコアの処理能力とプロセスの処理時間に応じて、ＣＰＵコアにプロセスを割り当てる負荷分散技術が提案されている（例えば、特許文献１参照。）。また、ＣＰＵコア毎に待機状態のタスクの数を監視し、そのタスクを処理するＣＰＵコアの数を調整することで負荷を分散する技術が提案されている（例えば、特許文献２参照。）。

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

しかしながら、特許文献１記載の負荷分散技術は、各ＣＰＵコアにどの程度の余裕があるかを考慮していないので、処理能力の高いＣＰＵコアに処理時間の短いプロセスを分散しても、処理効率が向上するとは限らないという問題がある。また、特許文献２記載の負荷分散技術では、負荷の分散候補であるＣＰＵコアがタスクを受けられるか否かを判定するが、３以上のＣＰＵコア間の負荷の調整について考慮されていないという問題がある。すなわち、特許文献２記載の負荷分散技術のように、分散候補のＣＰＵコアにタスクを受けられるか問い合わせる方法では、負荷に余裕のあるＣＰＵコアにたどり着くまで総当たりで問い合わせる必要が生じてしまい、そのためのオーバヘッドが無視できなくなる。

また、比較的高性能なＥＣＵにはＯＳが搭載されることがあるが、タスクを実行しないアイドル状態では、ＯＳがＲＯＭサムチェックなどの故障検出のためのアイドルタスクを実行することがあり、負荷に余裕のあるＥＣＵを検出すること自体が困難な場合もある。

本発明は、上記課題に鑑み、処理能力に余裕がある電子制御ユニットに効率的に負荷分散できる車載システム及び負荷分散方法を提供することを目的とする。

上記課題に鑑み、本発明は、車載ＬＡＮを介して接続された複数の電子制御ユニットを有する車載システムにおいて、各電子制御ユニットは、当該電子制御ユニットの余剰処理能力を測定する、ハードウェアで実装された測定手段（例えば、ＭＴ−ＣＴＬ２１，ＳＬ−ＣＮＴ２２）と、余剰処理能力を他の電子制御ユニットに通知する通知手段（例えば、ＣＡＮＣ１４、カウント通知部３１）と、他の電子制御ユニットから通知された余剰処理能力を各電子制御ユニットに対応づけて登録したテーブル（例えば、ＬＢ−ＴＢＬ２５）と、他の電子制御ユニットの余剰処理能力に基づき、他の電子制御ユニットに、当該電子制御ユニットの負荷を分散する負荷分散手段（例えば、負荷分散部３４）と、を有する、ことを特徴とする。

上記課題に鑑み、処理能力に余裕がある電子制御ユニットに効率的に負荷分散できる車載システム及び負荷分散方法を提供することができる。

負荷分散の手順を模式的に説明する図の一例である。 ＥＣＵに搭載されるマイコンの概略ハードウェア構成図の一例である。 スレッドとＳＬ−ＣＮＴの関係を説明する図の一例である。 各実行リソースに割り当てられるスレッドを模式的に示す図の一例である。 各ＥＣＵが有するＬＢ−ＴＢＬの一例を示す図である。 マイコンの機能ブロック図の一例である。 負荷分散後のＥＣＵ＃ＢのＬＢ-ＴＢＬの一例を示す図である。 車載システム１００が負荷分散する手順を示すシーケンス図の一例である。 各ＥＣＵが、１つのＥＣＵが負荷分散した結果を共有したＬＢ−ＴＢＬの一例を示す図である。

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

図１は、負荷分散の手順を模式的に説明する図の一例である。４つのＥＣＵ＃Ａ〜ＥＣＵ＃Ｄが車載ＬＡＮ２６を介して接続されている。ＥＣＵ＃Ａ〜ＥＣＵ＃Ｄは余剰処理量をカウントするＳＬ−ＣＮＴ２２Ａ〜２２Ｄ（ＥＣＵ＃Ｂは不図示）を有し、ＥＣＵ＃Ａ〜ＥＣＵ＃ＤはＳＬ−ＣＮＴ２２Ａ〜２２Ｄでカウントしたカウント値を同報的かつ定期的に他のＥＣＵに送信する。図１では、ＥＣＵ＃Ａ、ＥＣＵ＃Ｂ及びＥＣＵ＃Ｄが、それぞれのカウント値を送信し、ＥＣＵ＃Ｂが受信する様子を示している。

ＥＣＵ＃Ｂは、ＥＣＵ＃Ａ、ＥＣＵ＃Ｂ及びＥＣＵ＃Ｄから受信したカウント値をＬＢ−ＴＢＬ２５Ｂに登録する。したがって、ＥＣＵ＃ＢはＬＢ−ＴＢＬ２５Ｂを参照することで、どのＥＣＵの処理能力が余剰しているかを検出することができ、ＥＣＵ＃Ｂは処理能力が余剰している、換言すればカウント値が最も大きいＥＣＵに、負荷を分散させることができる。図１では、ＥＣＵ＃Ａのカウント値が最も大きいので、ＥＣＵ＃ＢはＥＣＵ＃Ａに負荷を分散する。

ＥＣＵ＃Ｂは、処理能力が余剰しているＥＣＵ＃Ａに負荷を分散させることができるので、車載システム１００全体として効率的な負荷分散が可能になる。また、各ＥＣＵの処理負荷のピークに合わせて各ＥＣＵの処理能力を決定する必要がなくなるので、トータルのＥＣＵコストを低減できる。

図２は、ＥＣＵに搭載されるマイコン５０の概略ハードウェア構成図の一例を示す。マイコン５０は、ＣＰＵコア１２、ＲＯＭ１１、ＲＡＭ１３、ＤＭＡＣ（Direct Memory ACCESS Controller）１４、ＣＡＮＣ１５（CAN Controller）、及び、ＧＰ-ＩＯ（General Purpose IO）１６を有する。ＣＰＵコア１２とＲＯＭ１１、及び、ＣＰＵコア１２とＲＡＭ１３、ＤＭＡＣ１４、ＣＡＮＣ１５、ＧＰ−ＩＯ１６はバスを介して接続されている。

ＲＯＭ１１は、ＥＥＰＲＯＭなど書き換え可能な不揮発メモリであり、ＣＰＵコア１２が実行するプログラムを記憶している。ＲＡＭ１３は、ＣＰＵコア１２がプログラムやデータを一時的に格納する作業メモリであり、本実施例では後述するＬＢ−ＴＢＬ（Load Baclance TaBle）２５を記憶する。ＤＭＡＣ１４は、ＣＰＵコア１２を介することなくＧＰ−ＩＯ１６やＣＡＮＣ１５からＲＡＭ１３へ、ＲＡＭ１３からＧＰ−ＩＯ１６やＣＡＮＣ１５へ、データをＤＭＡ転送する。ＣＡＮＣ１５は、他のＥＣＵとＣＡＮ（Controller Area Network）通信するためのコントローラであり、本実施形態ではＳＬ−ＣＮＴ２２がカウントしたカウント値を送信し、また、負荷分散するために必要なデータを送信する。ＣＡＮの他、ＦｌｅｘｒａｙやＬＩＮ等を通信態様は問わない。例えば、ＣＡＮ通信では、送受信する単位であるフレームのフォーマットが定められている。フレームには、データの内容を示すＩＤフィールド、データ長を示すＤＬＣフィールド、データを格納するＤＡＴＡフィールド等の各フィールドが定められている。ＧＰ−ＩＯ１６は、入力又は出力インターフェイスであり、センサやアクチュエータ、スイッチ等が接続される。

ＣＰＵコア１２は、ＩＦＵ（Instraction Fetch Unit）１７、ＰＣ（Program Counter）１８、ＩＤ（Instraction Dispatcher）１９、ＥＸＥ（EXEcute Unit）２３、ＲＥＧ（REGister）２４、ＭＴ−ＣＴＬ（Multi Thread ConTroller）２１、及び、ＳＬ−ＣＮＴ（Surplus Load Controller）２２を有する。

ＩＦＵ１７は、ＰＣ１８が指示するＲＯＭ１１のアドレスから命令を読み出す。図示するように、ＩＦＵ１７には複数のＰＣ１８が接続されている。これは、ＥＸＥ２３がマルチスレッドに対応しており１周期で複数の命令を実行することに対応したものである。したがって、ＩＦＵ１７はＰＣ１８の数だけ、ＲＯＭ１１から命令を読み出すことになる。ＣＰＵコア１２が異なるスレッドを実行する場合、ＰＣ１８が指示するアドレスも異なるが、同じスレッドを平行に実行したり、後述するアイドル状態の命令を実行する場合等、ＰＣ１８が指示するアドレスは同じでもよい。

ＩＤ１９は、ＩＦＵ１７が読み出した命令を解読し、解読結果に応じた命令をＥＸＥ２３に発行する。例えば、ＥＸＥ２３が加算器、浮動小数点演算器、乗算器、除算機等を備えている場合、ＩＤ１９はこれらを動作させる命令を発行する。ＥＸＥ２３は、１周期の間を時分割で各命令を実行して結果をＲＥＧ２４に格納する。スレッドの数だけＥＸＥ２３が存在してもよい。以下、スレッドとＥＸＥ２３を区別するため、ＥＸＥ２３が１つのスレッドを実行するための資源（リソース）を「１実行リソース」と称す。

〔余剰の処理能力のカウント〕
ＭＴ−ＣＴＬ２１は、マルチスレッド機能の制御ユニットであり、例えばスレッド間に時間依存の関係があったり、優先度が定められている場合、スレッド毎に命令の実行順を調整することができる。また、本実施形態のＭＴ−ＣＴＬ２１は、ＩＤ１９が解読した命令に基づきＳＬ−ＣＮＴ２２のカウント値をカウントアップする。

図３は、スレッドとＳＬ−ＣＮＴ２２の関係を説明する図の一例である。図３では、ＣＰＵコア１２は８つのスレッドを１周期（例えば１クロック）で実行するものとする。したがって、このＣＰＵコア１２は１周期で８実行リソースを提供でき、ＥＸＥ２３は、実行リソースＴH０〜７を用いて８つのスレッドを１周期で実行する。実行リソースＴＨ０〜３は実需のスレッド、例えば、センサが検出した信号に演算を施したりアクチュエータを制御するスレッドを実行する。実行リソースＴＨ７は、余剰の処理能力（カウント値）を他のＥＣＵに通知する通知スレッドを実行する。すると、実行リソースＴＨ４〜６は、実需のスレッドを実行しないので余剰の処理能力となる。ＭＴ−ＣＴＬ２１は、実需のスレッドを実行しない実行リソースＴＨ４〜６をＳＬ−ＣＮＴ２２を用いてカウントする。

余剰の処理能力のカウントについて説明する。本実施形態では、実需のスレッドを実行しない実行リソースを余剰の処理能力として扱い、この数をカウントする。

図４は、各実行リソースに割り当てられるスレッドを模式的に示す図の一例である。例えば、実行リソースＴＨ０にはＲ０のスレッドが、実行リソースＴＨ１にはＲ１のスレッドが、実行リソースＴＨ２にはＲ２のスレッドが、実行リソースＴＨ３にはＲ３のスレッドが、それぞれ１周期毎に割り当てられ、実行リソースＴＨ７には通知スレッドが定期的に割り当てられる。スレッドＲ０〜Ｒ３は実需のスレッドである。これに対し、実行リソースＴＨ４〜ＴＨ６には、実需のスレッドＲ４〜Ｒ６が割り当てられることはあっても、アイドル状態を多く含む。ＭＴ−ＣＴＬ２１は実行リソースがアイドル状態になった回数をカウントする。

ここで、アイドル状態の実行リソースがどのような処理を実行するかはマイコン５０によって様々である。例えば、定期的にＲＯＭサムチェックするマイコン５０もあれば、ＮＯＰ（No Operation）命令を繰り返し実行するマイコン５０もある。そこで、本実施形態では、アイドル状態を示す命令をアイドル状態の開始時と、終了時に挿入する。図４では、Ｉｓ（Ｉｄｌｅ Ｓｔａｒｔ）がアイドル状態の開始時を示す命令（スレッド）を、Ｉe（Ｉｄｌｅ Ｅｎｄ）がアイドル状態の終了時を示す命令（スレッド）を、それぞれ示す。ＭＴ−ＣＴＬ２１はＩｓ又はＩｅの数をカウントすることで、余剰の処理能力の大きさを測定することができる。

Ｉｓ及びＩｅを実行リソースに割り当てる方法は、大きく２つある。例えば、並列に実行可能な命令を含むソースコードをコンパイラがコンパイルする場合でも、実行リソースの数だけは並列に実行する命令がない場合がある。この場合、コンパイラは並列に命令を割り当てない実行リソースにIｓを割り当て、実需の命令を割り当てる直前にIeを割り当てる。このように、ソースコードやコンパイラによってはコンパイル時に余剰の実行リソースが定まる。

また、ＯＳのスケジューラがＩｓ及びＩｅを実行リソースに割り当てる場合がある。ＯＳはスレッドを実行リソースに割り当てるが、実行リソースの数以上のスレッドを並列に実行リソースに割り当てる状況でなければ、いくつかの実行リソースがアイドル状態となる。このような場合、ＯＳはアイドル状態の開始時にその実行リソースにＩｓを割り当て、実需の命令を割り当てる直前にIeを割り当てる。アイドル状態の間、ＯＳは、ＲＯＭサムチェックやＮＯＰ命令等、アイドル状態で必要な処理を実行できる。

ＭＴ−ＣＴＬ２１は特定の命令Ｉｓ又はＩｅが検出されると、検出した数だけＳＬ−ＣＮＴ２２をカウントアップする。１周期の間に命令Ｉｓ又はＩｅが検出された実行リソースが複数あれば、その数だけＳＬ−ＣＮＴ２２をカウントアップする。Ｉｓ又はＩｅのいずれかをカウントすればよい。なお、このようにＩｓ又はＩｅをカウントすると、ＳＬ−ＣＮＴ２２のカウント値は時間と共に増大するので、ＭＴ−ＣＴＬ２１は定期的にＳＬ−ＣＮＴ２２をリセットする。リセットする周期は、例えば、カウント値を他のＥＣＵに通知するタイミングである。こうすることで、各ＥＣＵは最も最近の余剰の処理能力を他のＥＣＵに通知することができる。また、ＭＴ−ＣＴＬ２１をハードウェアで実装し、自律で余剰の処理能力をカウントするので、ＯＳ等が余剰の処理能力をカウントする必要がなく、スレッドの処理速度に影響を与えることがない。

〔ＬＢ−ＴＢＬ２５〕
図２に戻り、ＬＢ-ＴＢＬ２５Ａ〜２５Ｄについて説明する。各ＥＣＵは、他のＥＣＵから通知されたカウント値を登録したＬＢ−ＴＢＬ２５Ａ〜２５Ｄを有する。
図５は、各ＥＣＵが有するＬＢ−ＴＢＬ２５Ａ〜２５Ｄの一例を示す図である。ＥＣＵ＃Ａは、ＥＣＵ＃Ｂ、ＥＣＵ＃Ｃ及びＥＣＵ＃Ｄのカウント値から成るＬＢ−ＴＢＬ２５Ａを有し、ＥＣＵ＃Ｂは、ＥＣＵ＃Ａ、ＥＣＵ＃Ｃ及びＥＣＵ＃Ｄのカウント値から成るＬＢ−ＴＢＬ２５Ｂを有し、ＥＣＵ＃Ｃは、ＥＣＵ＃Ａ、ＥＣＵ＃Ｂ及びＥＣＵ＃Ｄのカウント値から成るＬＢ−ＴＢＬ２５Ｃを有し、ＥＣＵ＃Ｄは、ＥＣＵ＃Ａ、ＥＣＵ＃Ｂ及びＥＣＵ＃Ｃのカウント値から成るＬＢ−ＴＢＬ２５Ｄを有する。各ＥＣＵは、ＬＢ−ＴＢＬ２５Ａ〜２５Ｄを参照することで、どのＥＣＵにどのくらいの余剰の処理能力があるかを検出できる。

図５のＬＢ−ＴＢＬ２５Ａ〜２５Ｄでは、カウント値と共に各ＥＣＵの動作クロック周波数が登録されている。各ＥＣＵの処理能力が全て同程度であれば、余剰の処理能力が最も大きいＥＣＵに負荷を分散すればよいが、ＥＣＵの処理能力が異なる場合、カウント値が大きくても本来の処理能力が低いＥＣＵが存在することになる。いずれかのＥＣＵが、カウント値が大きく本来の処理能力が低い他のＥＣＵに負荷を分散すると、分散先のＥＣＵの処理負荷が過剰に大きくなってしまう。そこで、ＬＢ−ＴＢＬ２５Ａ〜２５Ｄには、各ＥＣＵの動作クロック周波数を登録しておき、動作クロック周波数に応じてカウント値を重み付けすることで、各ＥＣＵの余剰の処理能力を正確に監視することを可能にする。

このため、各ＥＣＵは、自らの動作クロック周波数を同報的に他のＥＣＵに送信する。ここで、ＥＣＵ＃Ａ〜ＥＣＵ＃Ｄが起動するか否かは、ＩＧ（イグニッション）オン、ＡＣＣオン又はメインシステムオンに対し一様でなく、電力が供給されてからＥＣＵが起動するまでの時間もそれぞれ異なることが多い。そこで、本実施形態では、ＥＣＵの備えたＣＡＮＣ１５が通信可能となって以降、遅滞なくＥＣＵが動作クロック周波数を同報的に送信するものとする。すなわち、ＣＡＮＣ１５が起動して通信可能な状態になるとＣＰＵコア１２に割り込みして、ＣＰＵコア１２が通知スレッドを実行する。したがって、動作クロック周波数を受信した各ＥＣＵは、動作クロック周波数により処理能力を取得できると共に、動作クロック周波数を送信したＥＣＵに対し負荷分散できること検出できる。なお、このように各ＥＣＵが動作クロック周波数を他のＥＣＵに通知するのでなく、各ＥＣＵが予め他のＥＣＵの動作クロック周波数を記憶していてもよい。

図６は、ＥＣＵの機能ブロック図の一例を示す。図６では、通知する側のＥＣＵ＃Ａと、負荷分散をＥＣＵ＃Ａに要求するＥＣＵ＃Ｂとを示した。他のＥＣＵ＃Ｃ，ＥＣＵ＃Ｄも同様の機能ブロックを有する。ＥＣＵ＃Ａは、ＣＰＵコア１２が通知スレッドを実行することで実現されるカウンタ通知部３１、負荷分散の要求を受けて処理を代行する処理代行部３２、を有する。ＥＣＵ＃Ｂは、負荷分散をＥＣＵ＃Ａに要求する負荷分散部３４、を有する。

上記のように、カウンタ通知部３１はＣＡＮＣ１５の割り込みにより起動して、自らの動作クロック周波数を、他のＥＣＵに送信する。例えば、カウンタ通知部３１はＩＤコードに「ＦＦＦＦ」を設定することで、同報的に自らの動作クロック周波数をＣＡＮＣ１５を介して送信する。ここで、ＥＣＵ＃Ａが起動しても、他のＥＣＵが起動していない場合があるので、カウンタ通知部３１は、例えば、起動後、数分間、定期的に自らの動作クロック周波数を同報的に送信する。各ＥＣＵに個別に送信し、応答のないＥＣＵにだけ動作クロック周波数の送信を繰り返してもよい。

また、カウンタ通知部３１は、タイマ３３にカウント値の通知のサイクル時間を設定し、タイマ３３をスタートさせる。タイマ３３に設定されるサイクル時間は例えば数マイクロ秒から数ミリ秒である。サイクル時間が経過するとタイマ３３がＣＰＵコア１２に割込みするので、ＣＰＵコア１２は通知スレッドを実行することでカウンタ通知部３１が実現される。カウンタ通知部３１は、ＳＬ−ＣＮＴ２２からカウント値を読み出し、同報的にＣＡＮＣ１５を介して送信する。

他のＥＣＵのＣＡＮＣ１５はＥＣＵ＃Ａのカウント値を受信して、ＩＤデータに基づき受信したデータがカウント値であることを検出すると、ＤＭＡＣ１４にカウント値の処理を依頼する。ＤＭＡＣ１４はＲＡＭ（ＬＢ−ＴＢＬ２５）１３にカウント値をＤＭＡ転送する。各ＥＣＵがカウント値の送信及びＬＢ−ＴＢＬ２５Ａ〜２５Ｄへの記憶を繰り返すことで、ＬＢ−ＴＢＬ２５Ａ〜２５Ｄには最も最近の余剰の処理能力が登録される。

〔負荷分散〕
負荷分散部３４は、ＥＣＵ＃ＢがＥＣＵ＃Ａに負荷分散する候補のスレッドの処理負荷を分散候補リスト３５から抽出する。これは、負荷分散先のＥＣＵ＃Ａの余剰の処理能力と比較するためである。すなわち、負荷を分散するためにＥＣＵ＃Ａに送信したスレッドの処理負荷が、ＥＣＵ＃Ａの余剰の処理能力を超えていると、適切な負荷分散とならない場合があるからである。ここで、各ＥＣＵの実行するスレッドは既知なので、処理負荷は固定値である。そこで、各ＥＣＵは、負荷分散する候補のスレッドの処理負荷（以下、「スレッド負荷」という）を、予め分散候補リスト３５に登録しておく。

図６には、スレッドＳｂ１〜Ｓｂ３のスレッド負荷「b1b1b1b1」「b2b2b2b2」「b3b3b3b3」が登録されている。スレッド負荷は、例えばＭＩＰＳ値などで指標化されることが多い。単位時間当たりに実行要求される命令数が大きいスレッドほど、ＣＰＵコア１２にとって処理負荷が大きいと言える。考え方としては、このＭＩＰＳ値を通知のサイクル時間当たりの命令数に補正すれば、通知のサイクル時間における余剰の処理能力で、分散候補のスレッドを実行可能と推定できる。すなわち、分散候補リスト３５に登録される各スレッドのスレッド負荷は、例えば、各スレッドのＭＩＰＳ値を通知サイクル時間で割った値である。

なお、分散候補のスレッドは、他のＥＣＵにて実行できるものでなければならない。実行できるかどうかは、負荷分散の形態に応じて異なるが、ＯＳや実行環境が共通でアプリとしてのスレッドが実行できることが必要である。また、ＥＣＵ＃Ｂに接続されたアクチュエータの制御までＥＣＵ＃Ａに負荷分散するのであれば、ＥＣＵ＃Ａがアクチュエータのドライバを有し、アクチュエータに接続するためのＩＯを備えているか、又は、ＥＣＵ＃ＢのＩＯをＥＣＵ＃Ａと共用する手段が必要となる。

また、負荷分散部３４は負荷分散の前に、ＥＣＵ＃Ｂの処理負荷に基づき、分散候補リスト３５に登録されたスレッドの候補を、ＥＣＵ＃Ａに負荷分散すべきか否かを判定する。すなわち、ＥＣＵ＃Ｂの処理負荷がある程度大きくなければ、負荷分散する必要性が低いからである。一般的なＯＳは、ＣＰＵコア１２の処理負荷を監視している。ＯＳは、例えば、ＣＰＵコア１２の使用率やスレッドキューにおいて実行待ちをしているスレッドの数から、ＥＣＵ＃Ｂの処理負荷を監視している。負荷分散部３４は、この処理負荷が所定値以上の場合、分散候補リスト３５のスレッドをＥＣＵ＃Ａに負荷分散することを試みる。

まず、負荷分散部３４は、分散候補リスト３５からスレッド負荷の高い順にスレッド負荷を読み出す。そして、ＬＢ−ＴＢＬ２５Ｂから最も大きなカウント値を読み出す。負荷分散部３４は、最も大きいスレッド負荷と最も大きいカウント値を比較して、スレッド負荷の方が小さい場合、最も大きいスレッド負荷のスレッドを最も大きいカウント値に対応づけられたＥＣＵ（図６ではＥＣＵ＃Ａとする）に負荷分散できると判定する。スレッド負荷がカウント値以上の場合、負荷分散部３４は次に大きいスレッド負荷を分散候補リスト３５から読み出し、同様の比較を繰り返す。

例えば、図６の分散候補リスト３５においてb1b1b1b1＞b2b2b2b2＞b3b3b3b3、ＥＣＵ＃ＢのＬＢ−ＴＢＬ２５Ｂにおいてxxxx＞zzzz＞wwwwと仮定すると、負荷分散部３４は、xxxx＞b1b1b1b1の場合、スレッドＳｂ１をＥＣＵ＃Ａに負荷分散する。xxxx＞b1b1b1b1でない場合、負荷分散部３４は、xxxx＞b2b2b2b2の場合、スレッドＳｂ２をＥＣＵ＃Ａに負荷分散する。xxxx＞b2b2b2b2でない場合、負荷分散部３４はxxxx＞b3b3b3b3の場合、スレッドＳｂ３をＥＣＵ＃Ａに負荷分散する。

なお、負荷分散部３４は、スレッドＳｂ１をＥＣＵ＃ＡだけでなくＥＣＵ＃Ｃに負荷分散してもよい。スレッドＳｂ１の一部をＥＣＵ＃Ａに、残りをＥＣＵ＃Ｃに負荷分散することで、ＬＢ−ＴＢＬ２５のカウンタ値がスレッド負荷未満でも、負荷の分散が可能となり、より効率的な負荷分散が可能となる。この場合、分散候補リスト３５に、ＥＣＵ＃Ｂが実行するスレッド毎に分散可能な部分をアドレス等で指定しておき、該部分毎にスレッド負荷を登録しておく。

〔動作クロック周波数による重み付け〕
ここで、動作クロック周波数がＥＣＵ間で異なる場合の取り扱いを説明する。スレッド負荷は、そのＥＣＵの動作クロック周波数でスレッドを実行した場合の処理負荷である。したがって、動作クロック周波数がＥＣＵ間で異なる場合、負荷分散部３４は、自分（ＥＣＵ＃Ｂ）の動作クロック周波数と他のＥＣＵの動作クロック周波数の比に応じて、カウント値を重み付けする。

図５に示したように、ＥＣＵ＃Ａ，ＥＣＵ＃Ｂの動作クロック周波数が１２８〔ＭＨｚ〕、ＥＣＵ＃Ｃの動作クロック周波数が６４〔ＭＨｚ〕、ＥＣＵ＃Ｄの動作クロック周波数が３２〔ＭＨｚ〕の場合、ＥＣＵ＃Ｂの負荷分散部３４は、ＬＢ−ＴＢＬ２５に登録されたカウント値に対し、次のように重み付けする。
重み付けされたＥＣＵ＃Ａのカウント値＝ 「ｘｘｘｘ」×１２８／１２８
重み付けされたＥＣＵ＃Ｃのカウント値＝ 「ｙｙｙｙ」× ６４／１２８
重み付けされたＥＣＵ＃Ｄのカウント値＝ 「ｗｗｗｗ」× ３２／１２８
すなわち、負荷分散部３４は、動作クロック周波数がＥＣＵ＃Ｂと同じＥＣＵ＃Ａのカウント値は重み付けしない。動作クロック周波数がＥＣＵ＃Ｂの半分のＥＣＵ＃Ｃのカウント値は、「０．５」で重み付けする。動作クロック周波数がＥＣＵ＃Ｂの１／４のＥＣＵ＃Ｄのカウント値は、「０．２５」で重み付けする。こうすることで、動作クロック周波数の異なるＥＣＵのカウント値と、分散候補リスト３５のスレッド負荷を的確に比較することができる。したがって、負荷分散部３４は、スレッド負荷と重み付け後のカウント値を比較して、スレッド負荷の方が小さい場合、そのＥＣＵ（図６ではＥＣＵ＃Ａとする）にそのスレッドを負荷分散できると判定する。

負荷分散できるＥＣＵ＃Ａを決定した負荷分散部３４は、スレッドの実行をＥＣＵ＃Ａに依頼するための一連の依頼用データをＥＣＵ＃Ａに送信する。依頼用データの粒度は、例えば、アプリケーション全体、アプリケーションの中の関数、アプリケーションの中の所定のサブルーチン等である。負荷分散部３４は、粒度に応じてＲＯＭ１１からプログラムを読み出す。また、負荷分散するまでにＥＣＵ＃Ｂが実行した処理結果があればＲＡＭ１３から読み出す。また、実行中の処理経過があれば、ＲＥＧ２４やＰＣ１８から読み出す。負荷分散部３４はこれらＥＣＵ＃Ａがスレッドを実行するために必要な依頼用データをＥＣＵ＃Ａに送信する。

そして、負荷分散部３４は、ＥＣＵ＃Ａに負荷分散したスレッドのスレッド負荷をＬＢ−ＴＢＬ２５Ｂのカウント値から減じる。
図７は、負荷分散後のＥＣＵ＃ＢのＬＢ−ＴＢＬ２５Ｂの一例を示す。スレッド負荷ｂ１をＥＣＵ＃Ａに負荷分散した結果、ＥＣＵ＃Ａの余剰の処理能力は少なくなる。これをＬＢ−ＴＢＬ２５Ｂに反映させるため、負荷分散部３４は、ＬＢ−ＴＢＬ２５ＢにおけるＥＣＵ＃Ａのカウント値「ｘｘｘｘ」を「b1b1b1b1」だけ減じる。こうすることで、例えば、ＥＣＵ＃Ｂが続けてスレッドｂ２をＥＣＵ＃Ａに負荷分散することを防止できる。

なお、カウント値の減算においても、動作クロック周波数を考慮することが好ましい。図７では、ＥＣＵ＃ＡとＥＣＵ＃Ｂの動作クロック周波数が同じなので、負荷分散部３４は「ｘｘｘｘ」からそのまま「b1b1b1b1」を減じた。仮に、負荷分散部３４がＥＣＵ＃Ｃにスレッドｂ１を負荷分散した場合、ＥＣＵ＃Ｃは動作クロック周波数がＥＣＵ＃Ｂの半分なので、負荷分散部３４はスレッド負荷を２倍した値をＥＣＵ＃Ｃのカウント値から減じる。すなわち、ＥＣＵ＃Ｃのカウント値は、「ｚｚｚｚ」−２×「b1b1b1b1」となる。同様に、仮にＥＣＵ＃Ｄに負荷分散した場合、ＥＣＵ＃Ｄのカウント値は、「ｗｗｗｗ」−４×「b1b1b1b1」となる。

図６に戻り、処理代行部３２は、依頼用データに基づきＥＣＵ＃Ｂから負荷分散されたスレッドｂ１を実行する。処理代行部３２は、例えば、依頼用データに含まれるプログラムをＲＡＭ１３に記憶して、そのアドレスをＰＣ１８にセットして、スレッドｂ１を実行する。そして、処理代行部３２は、処理結果をＥＣＵ＃Ｂに送信する。ＥＣＵ＃Ｂは、処理結果に基づき、ＥＣＵ＃Ｂに接続されたアクチュエータ等を制御することができる。また、ＥＣＵ＃Ａが、ＥＣＵ＃Ｂに接続されたアクチュエータのＩＯを有する場合、ＥＣＵ＃Ａが直接、ＥＣＵ＃Ｂに接続されたアクチュエータを制御することができる。

〔動作手順〕
図８は、車載システム１００が負荷分散する手順を示すシーケンス図の一例を示す。図８のシーケンス図は、カウント値の通知のサイクル時間毎に繰り返し実行される。各ＥＣＵのＭＴ−ＣＴＬ２１は１周期毎にスレッドがアイドル状態になった回数をＳＬ−ＣＮＴ２２にてカウントしている。そして、カウンタ通知部３１は、タイマ３３を利用して、通知のサイクル時間毎にカウント値を同報的に各ＥＣＵに送信する（Ｓ１０〜Ｓ４０）。なお、各ＥＣＵはＣＡＮＣ１５が起動した直後、動作クロック周波数を同報的に他のＥＣＵに送信する。

そして、各ＥＣＵの負荷分散部３４は、ＥＣＵの処理負荷が所定値以上か否かを判定する（Ｓ５０）。処理負荷が所定値以上でない場合（Ｓ５０のＮｏ）、処理負荷を分散する必要がないので、図８の手順は終了する。

処理負荷が所定値以上の場合（Ｓ５０のＹｅｓ）、処理負荷を分散することでＥＣＵ＃Ｂの処理に遅延が生じることを予防できるので、負荷分散部３４は、ＬＢ−ＴＢＬ２５Ｂに登録された最も大きいカウント値が、スレッド負荷以上か否かを判定する（Ｓ６０）。負荷分散部３４は、分散候補リスト３５から最も大きいスレッド負荷を読み出し、各ＥＣＵのカウント値を動作クロック周波数で重み付けした後、両者を比較する。

比較の結果、カウント値がスレッド負荷未満の場合（Ｓ６０のＮｏ）、負荷分散すると、分散先のＥＣＵの処理の余剰能力を超えるおそれがあるので、負荷分散部３４は負荷を分散しない。カウント値がスレッド負荷以上の場合（Ｓ６０のＹｅｓ）、負荷分散しても、分散先のＥＣＵの処理の余剰能力を超えずにＥＣＵ＃Ｂの負荷を分散できるので、負荷分散部３４は依頼用データをＥＣＵ＃Ａに送信する（Ｓ７０）。また、負荷分散部３４は、ＥＣＵ＃Ａに負荷分散したスレッドのスレッド負荷をＥＣＵ＃ＢのＬＢ−ＴＢＬ２５Ｂのカウント値から減じる。

ＥＣＵ＃Ａの処理代行部３２は、依頼用データに基づきＥＣＵ＃Ｂのスレッドを実行する（Ｓ８０）。また、処理代行部３２はスレッドの処理結果をＥＣＵ＃Ｂに送信する。処理結果を受信してＥＣＵ＃Ｂは例えばアクチュエータを制御することができる（Ｓ９０）。

本実施形態の各ＥＣＵの余剰の処理能力を他のＥＣＵが共有することで、余剰の処理能力を有するＥＣＵに的確に負荷分散を依頼できる。また、他のＥＣＵの余剰の処理能力を利用することを前提にマイコン５０の処理能力を決定できるので、車載システム１００全体として備えるべきハードウェア処理能力を軽減できＥＣＵのコスト増を抑制できる。また、ＭＴ−ＣＴＬ２１をハードウェアで実装しＭＴ−ＣＴＬ２１はＩＤ１９に連動して自律で余剰の処理能力をカウントするので、ＯＳ等が余剰の処理能力をカウントする必要がなく、スレッドの処理速度に影響を与えることがない。また、ＲＡＭ１３などのメモリを増強する必要もない。また、動作クロック周波数に代表される各ＥＣＵの処理能力により余剰の処理能力を重み付けするので、各ＥＣＵの処理能力が異なっていても、各ＥＣＵが余剰の処理能力を正確に把握できる。

〔好適な変形例〕
いくつのかの好適な変形例について説明する。
ＥＣＵ＃Ｂの負荷分散部３４は、ＥＣＵ＃Ａに負荷分散したスレッドのスレッド負荷をＬＢ−ＴＢＬ２５Ｂのカウント値から減じる、と説明したが、ＥＣＵ＃Ｂの負荷分散部３４は他のＥＣＵにも負荷分散したスレッドのスレッド負荷を通知して、各ＥＣＵに、各ＥＣＵのＬＢ−ＴＢＬ２５Ａ〜２５Ｄのカウント値からスレッド負荷を減じさせてもよい。こうすることで、各ＥＣＵが負荷分散の結果、ＥＣＵ＃Ａの余剰の処理能力が減少したことを共有できる。

図９は、各ＥＣＵが、１つのＥＣＵが負荷分散した結果を共有したＬＢ−ＴＢＬ２５Ａ〜２５Ｄの一例を示す。このような処理は、負荷分散したＥＣＵ＃Ｂの負荷分散部３４が、ＥＣＵ＃Ｃ及びＥＣＵ＃Ｄにスレッド負荷「b1b1b1b1」を通知することで実現する。

また、この場合も、動作クロック周波数を考慮して、スレッド負荷をＬＢ−ＴＢＬ２５Ａ〜２５Ｄのカウント値から減じることが好ましい。図８の例では、ＥＣＵ＃ＡとＥＣＵ＃Ｂの動作クロック周波数が同じなので、動作クロック周波数を考慮しても、ＥＣＵ＃ＣとＥＣＵ＃ＤのＬＢ−ＴＢＬ２５Ｃ、２５Ｄにて、カウント値「ｘｘｘｘ」から減じられる値は「b1b1b1b1」のままである。

また、負荷分散部３４は、ＬＢ−ＴＢＬ２５Ｂにおいて最も大きなカウント値を有するＥＣＵ＃Ａを負荷分散の対象としたが、負荷分散する対象のＥＣＵを、分散対象のスレッドのスレッド負荷に最適なＥＣＵとしてもよい。こうすることで、例えば、ＥＣＵ＃Ｃ又はＥＣＵ＃ＤがＥＣＵ＃Ａの余剰の処理能力を利用可能となる。

具体的には、ＥＣＵ＃Ｂの負荷分散部３４は、分散候補リスト３５を参照し最も大きなスレッド負荷「b1b1b1b1」を読み出す。また、ＬＢ−ＴＢＬ２５Ｂを参照し、スレッド負荷「b1b1b1b1」よりも大きく、その中で最も小さいカウント値を探索する。例えば、動作クロック周波数により重み付けすると、ＥＣＵ＃Ａのカウント値は「xxxx」、ＥＣＵ＃Ｃのカウント値は「０．５×zzzz」、ＥＣＵ＃Ｄのカウント値は「０．２５×wwww」、である。負荷分散部３４は、これらから最も小さいカウント値を探し、スレッド負荷「b1b1b1b1」と比較する。例えば、「xxxx」＞「０．５×zzzz」＞「０．２５×wwww」の場合、負荷分散部３４は「０．２５×wwww」＞「b1b1b1b1」の場合は、ＥＣＵ＃ＤにスレッドＳｂ１を負荷分散し、「０．５×zzzz」＞「b1b1b1b1」の場合は、ＥＣＵ＃ＣにスレッドＳｂ１を負荷分散し、「xxxx」＞「b1b1b1b1」の場合は、ＥＣＵ＃ＡにスレッドＳｂ１を負荷分散する。なお、ＥＣＵ＃Ｂの負荷分散部３４は、最終的に「xxxx」＞「b1b1b1b1」が成立しなかった場合、分散候補リスト３５を参照し次に大きなスレッド負荷「b2b2b2b2」を読み出し、同様の作業を繰り返す。

こうすることで、スレッドＳｂ１に対し余剰の処理能力が必要充分なＥＣＵに負荷を分散できる。例えば、ＥＣＵ＃ＢがＥＣＵ＃Ｃに負荷分散した場合、ＥＣＵ＃Ａの余剰の処理能力は減少しないので、例えばＥＣＵ＃ＤがＥＣＵ＃Ａに負荷分散することが可能となり、より効率的な負荷分散が可能となる。

１１ ＲＯＭ
１２ ＣＰＵコア
１３ ＲＡＭ
１４ ＤＭＡＣ
１５ ＣＡＮＣ
２１ ＭＴ−ＣＴＬ
２２ ＳＬ−ＣＮＴ
２５ ＬＢ−ＴＢＬ
５０ マイコン
１００ 車載システム

Claims (10)

1. 車載ＬＡＮを介して接続された複数の電子制御ユニットを有する車載システムにおいて、
   各電子制御ユニットは、
   当該電子制御ユニットの余剰処理能力を測定する、ハードウェアで実装された測定手段と、
   前記余剰処理能力を他の電子制御ユニットに通知する通知手段と、
   他の電子制御ユニットから通知された前記余剰処理能力を各電子制御ユニットに対応づけて登録したテーブルと、
   他の電子制御ユニットの前記余剰処理能力に基づき、他の電子制御ユニットに当該電子制御ユニットの負荷を分散する負荷分散手段と、を有する、
   ことを特徴とする車載システム。
2. 各電子制御ユニットは、当該電子制御ユニットの処理能力情報を記憶しており、
   前記負荷分散手段は、前記処理能力情報により重み付けされた前記余剰処理能力に基づき、当該電子制御ユニットの負荷を分散する、
   ことを特徴とする請求項１記載の車載システム。
3. 前記処理能力情報は、当該電子制御ユニットが有するマイコンの動作クロック周波数である、
   ことを特徴とする請求項２記載の車載システム。
4. 前記通知手段は、当該電子制御ユニットが起動後、前記処理能力情報を他の電子制御ユニットに通知し、
   前記負荷分散手段は、前記処理能力情報を送信した送信元の電子制御ユニットを、負荷の分散候補とする、
   ことを特徴とする請求項１記載の車載システム。
5. 前記測定手段は、当該電子制御ユニットが実行する命令に基づき余剰処理能力を測定する、
   ことを特徴する請求項１記載の車載システム。
6. 当該電子制御ユニットが複数のスレッドを時間的に並行して実行するマルチスレッド機構を備える場合、
   前記測定手段は、スレッド毎にアイドル状態となった回数をカウントする、
   ことを特徴する請求項５記載の車載システム。
7. 前記負荷分散手段は、当該電子制御ユニットの負荷を分散した場合、
   前記テーブルにて負荷の分散先の電子制御ユニットに対応づけられた前記余剰処理能力から、分散した負荷に相当する値を減じる、
   ことを特徴とする請求項１記載の車載システム。
8. 前記負荷分散手段は、当該電子制御ユニットの負荷を分散した場合、
   負荷の分散先の電子制御ユニット以外の電子制御ユニットに、分散した負荷を通知する、
   ことを特徴とする請求項７記載の車載システム。
9. 前記負荷分散手段は、
   分散する負荷より大きい、前記テーブルに登録された前記余剰処理能力のうち、最も小さい余剰処理能力に対応づけられた各電子制御ユニットに、負荷を分散する、
   ことを特徴とする請求項１記載の車載システム。
10. 車載ＬＡＮを介して接続された複数の電子制御ユニットの負荷分散方法において、
    ハードウェアで実装された測定手段が、当該電子制御ユニットの余剰処理能力を測定するステップ、
    通知手段が、前記余剰処理能力を他の電子制御ユニットに通知するステップと、
    登録手段が、他の電子制御ユニットから通知された前記余剰処理能力を各電子制御ユニットに対応づけてテーブルに登録するステップと、
    負荷分散手段が、他の電子制御ユニットの前記余剰処理能力に基づき他の電子制御ユニットに、当該電子制御ユニットの負荷を分散するステップと、
    ことを特徴とする負荷分散方法。

Images