JP2018124856A - 電子制御装置 - Google Patents

Abstract

【課題】車両の状態に応じてバスに掛かる負荷が変化することに起因して発生する処理への影響を必要最小限に抑制するとともに、処理効率の低下を抑制する。【解決手段】ＥＣＵ１は、コア１１〜１４とＲＡＭ１６とバス１７とスタック領域３１〜３４を備える。ＥＣＵ１は、コア１１〜１４のそれぞれについて、スタック領域３１〜３４に登録されていているタスクによりバス１７を介してＲＡＭ１６へアクセスするときにバス１７に掛かるバス負荷の度合いを予測したバス負荷予測値を算出する。ＥＣＵ１は、コア１１〜１４のそれぞれについて、車両の状態に基づいて、バス負荷の許容値を示す閾値を算出する。ＥＣＵ１は、バス負荷予測値が閾値を超えないように、スタック領域３１〜３４に登録されているタスクをスタック領域３１〜３４から削除する。【選択図】図１

Description

本開示は、複数のコアを備える電子制御装置に関する。

特許文献１には、複数のコアを有するマルチコアプロセッサとメインメモリとがバスで接続された装置において、複数のタスクを複数のコアで並列に処理する場合に、複数タスクのメモリバス帯域負荷レベルの合計値が閾値以下となるように、優先度が高いタスクから順にコアに割り当てる技術が記載されている。

特開２０１６−９１４８９号公報

しかし、特許文献１に記載の技術では、バス負荷が固定の閾値以下になるように各コアにタスクを割り当てているため、車両制御のように各コアが別々の制御を行っており車両の運転状態に応じてバスに掛かる負荷が変わる場合に適切に対応できず、処理遅延などが発生してしまう恐れがあった。

本開示は、車両の状態に応じてバスに掛かる負荷が変化することに起因して発生する処理への影響を必要最小限に抑制するとともに、電子制御装置全体としての処理効率の低下を抑制することを目的とする。

本開示の一態様は、車両を制御する電子制御装置（１）であって、複数のコア（１１，１２，１３，１４）と、共有メモリ（１６）と、バス（１７）と、スタック領域（３１，３２，３３，３４）と、負荷予測部（Ｓ３３０〜Ｓ４１０）と、閾値算出部（Ｓ５１０〜Ｓ５７０）と、タスク削除部（Ｓ６１０〜Ｓ６４０，Ｓ７２０〜Ｓ７５０）とを備える。

共有メモリは、複数のコアのそれぞれがアクセス可能である。バスは、複数のコアと共有メモリとの間をデータの入出力が可能となるように接続する。スタック領域は、複数のコアのそれぞれに対応して設けられ、対応するコアが実行する１つ又は複数のタスクが登録される。

負荷予測部は、複数のコアのそれぞれについて、スタック領域に登録されていているタスクによりバスを介して共有メモリへアクセスするときにバスに掛かるバス負荷の度合いを予測したバス負荷予測値を算出するように構成される。

閾値算出部は、複数のコアのそれぞれについて、車両の状態に基づいて、バス負荷の許容値を示すバス負荷閾値を算出するように構成される。
タスク削除部は、複数のコアのそれぞれについて、バス負荷予測値がバス負荷閾値を超えないように、コアに対応したスタック領域に登録されているタスクをスタック領域から削除するように構成される。

このように構成された本開示の電子制御装置は、車両の状態に基づいてバス負荷閾値を算出するため、車両の状態に応じてバス負荷閾値を変更することができる。
例えば、複数のコアのうちの１つのコアを第１コアとし、第１コアとは異なる１つのコアを第２コアとする。そして、車両の状態に応じて、第１コアおよび第２コアが共有メモリへアクセスする頻度は変化する。

第１コアと第２コアの両方で共有メモリへアクセスする頻度が多い場合には、第１コアと第２コアの両方で共有メモリへアクセスすることができるように、第１コアと第２コアとの両方で、共有メモリへのアクセスを制限する必要がある。一方、第１コアで共有メモリへアクセスする頻度が多く、第２コアで共有メモリへアクセスする頻度が少ない場合には、第１コアで共有メモリへのアクセスを制限しなくても、第２コアにおけるタスク処理に影響を及ぼさない場合もある。逆に、第１コアで共有メモリへのアクセスを制限すると、電子制御装置の処理効率を無駄に低下させてしまう恐れがある。

これに対し、本開示の電子制御装置は、第１コアで共有メモリへアクセスする頻度が多く、第２コアで共有メモリへアクセスする頻度が少ない場合には、第１コアのバス負荷閾値を大きくして、共有メモリへのアクセス制限を緩和することができる。これにより、第１コアによる共有メモリへのアクセスを無駄に制限することがなくなる。

このように本開示の電子制御装置は、車両の状態に応じてバスに掛かる負荷が変化することに起因して発生する処理への影響を必要最小限に抑制するとともに、電子制御装置全体としての処理効率の低下を抑制することができる。

なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

ＥＣＵ１の構成を示すブロック図である。 指令コア処理を示すフローチャートである。 トリガー記録処理を示すフローチャートである。 予測値計算処理を示すフローチャートである。 バス負荷期待値を算出する具体例を示す図である。 閾値最適化処理を示すフローチャートである。 補正値表、修正値表および基本閾値表を示す図である。 自コアタスク制御処理を示すフローチャートである。 他コアタスク制御処理を示すフローチャートである。 コア１１〜１４の動作の具体例を示すシーケンス図である。

以下に本開示の実施形態を図面とともに説明する。
本実施形態の電子制御装置１（以下、ＥＣＵ１）は、車両に搭載され、図１に示すように、マイクロコンピュータ２（以下、マイコン２）を備える。ＥＣＵは、Electronic Control Unitの略である。

マイコン２は、コア１１，１２，１３，１４、ＲＯＭ１５、ＲＡＭ１６及びこれらの構成を接続するバス１７などから構成され、ＲＯＭ１５に記憶されたプログラムに基づいて、車両を制御するための各種制御処理を実行する。マイクロコンピュータの各種機能は、コア１１，１２，１３，１４が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ１５が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、コア１１〜１４が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、ＥＣＵ１を構成するマイクロコンピュータの数は１つでも複数でもよい。

コア１１は、車両のエンジンを制御するための各種制御処理を実行する。コア１２は、車両のモータを制御するための各種制御処理を実行する。コア１３は、ＣＡＮ通信を制御するための各種制御処理を実行する。ＣＡＮは、Controller Area Networkの略である。また、ＣＡＮは登録商標である。コア１４は、車両の電池を制御するための各種制御処理を実行する。

またマイコン２は、ローカルメモリ２１，２２，２３，２４を備える。ローカルメモリ２１，２２，２３，２４はそれぞれ、コア１１，１２，１３，１４に割り当てられたメモリである。すなわち、ローカルメモリ２１は、コア１１のみからアクセス可能に構成されている。同様に、ローカルメモリ２２，２３，２４はそれぞれ、コア１２，１３，１４のみからアクセス可能に構成されている。一方、ＲＡＭ１６は、コア１１，１２，１３，１４からアクセス可能に構成されている。

ローカルメモリ２１，２２，２３，２４には、それぞれコア１１，１２，１３，１４で実行予定のタスクを登録するスタック領域３１，３２，３３，３４が設けられている。
このように構成されたＥＣＵ１において、マイコン２のコア１１，１２，１３，１４は、指令コア処理と、トリガー記録処理と、予測値計算処理と、他コアタスク制御処理を実行する。

まず、指令コア処理の手順を説明する。指令コア処理は、ＥＣＵ１の動作中において繰り返し実行される処理である。
指令コア処理が実行されると、コア１１〜１４は、図２に示すように、まずＳ１０にて、予め設定されているバス負荷予測値演算イベント（以下、演算イベント）が発生したか否かを判断する。演算イベントとは、バス負荷が高くなることが予測される現象である。なお、「バス負荷が高い」とは、或るコアがバス１７を使用しているために他のコアがバス１７を長期間使用できずに待機している状態をいう。或るコアがバス１７を占有すると他のコアがバス１７にアクセスすることができずに、他のコアにおいて処理遅延またはタスク抜けが発生する。

「処理遅延」とは、各コアのスタック領域にタスクが登録された後に、登録されたタスクの少なくとも一部の処理が遅れる異常である。「タスク抜け」とは、上記スタック領域に登録されたタスクの少なくとも一部が実行されない異常である。

演算イベントとしては、例えば、各コアで実行予定のタスクを登録するスタック領域の使用率が予め設定された一定値を超えること、バス１７を長期占有する関数として予め設定された長期占有関数を含むタスクがスタック領域に登録されること等が挙げられる。

なお、関数がバス１７を長期占有するか否かは、関数を構成する複数のアセンブラコードのうち、ＲＡＭ１６に対して読み込み又は書き込みを行うアセンブラコードの処理時間の理論値に基づいて判断される。

Ｓ１０にて、演算イベントが発生していない場合には、Ｓ１０の処理を繰り返すことにより、演算イベントが発生するまで待機する。そして、演算イベントが発生すると、Ｓ２０にて、バス負荷予測値計算依頼（以下、計算依頼）を自身のコア以外のコア（以下、他コア）へ送信する。例えば、コア１２が実行している指令コア処理では、コア１１，１３，１４へ計算依頼を送信する。

そしてＳ３０にて、自身のコア（以下、自コア）のバス負荷予測値の計算開始を指示する計算開始フラグをセットする。計算開始フラグは、ローカルメモリ２１，２２，２３，２４のそれぞれに設けられている。Ｓ３０では、自コアに割り当てられているローカルメモリに設けられた計算開始フラグ（以下、自コアの計算開始フラグ）をセットする。

次にＳ４０にて、他コアからバス負荷計算完了通知（以下、完了通知）を受信したか否かを判断する。ここで、他コアから完了通知を受信していない場合には、Ｓ９０に移行する。一方、他コアから完了通知を受信した場合には、Ｓ５０にて、受信した完了通知に対応するコアのバス負荷計算完了フラグ（以下、完了フラグ）をセットする。なお、ローカルメモリ２１には、コア１１，１２，１３，１４の完了フラグが設けられている。同様に、ローカルメモリ２２，２３，２４には、コア１１，１２，１３，１４の完了フラグが設けられている。Ｓ５０では、例えば、コア１２から完了通知を受信した場合には、コア１２の完了フラグをセットする。

さらにＳ６０にて、完了通知とともに送信されたバス負荷期待値を、完了通知の送信元となるコアを示す送信元情報と対応付けて、自コアに割り当てられているローカルメモリ（以下、自コアのローカルメモリ）に記録する。そしてＳ７０にて、後述する補正トリガー情報を他コアから受信したか否かを判断する。ここで、他コアから補正トリガー情報を受信していない場合には、Ｓ９０に移行する。一方、他コアから補正トリガー情報を受信した場合には、Ｓ８０にて、受信した補正トリガー情報を、補正トリガー情報の送信元となるコアを示す送信元情報と対応付けて、自コアのローカルメモリに記録し、Ｓ６０に移行する。

そしてＳ９０に移行すると、セットされた完了フラグの数が全コア数（本実施形態では、４）に等しいか否かを判断する。すなわち、コア１１，１２，１３，１４の完了フラグがセットされた場合に、セットされた完了フラグの数が全コア数に等しいと判断する。

ここで、セットされた完了フラグの数が全コア数に等しくない場合には、Ｓ４０に移行する。一方、セットされた完了フラグの数が全コア数に等しい場合には、Ｓ１００にて、後述する閾値最適化処理を実行する。そして、閾値最適化処理が終了すると、Ｓ１１０にて、タスク制御依頼と、閾値最適化処理で算出された閾値とを他コアへ送信する。

次にＳ１２０にて、後述する自コアタスク制御処理を実行する。そして、自コアタスク制御処理が終了すると、Ｓ１３０にて、全コア（すなわち、コア１１〜１４）の完了フラグをクリアする。さらにＳ１４０にて、自コアのローカルメモリに記録されているバス負荷期待値と補正トリガー情報を消去して、指令コア処理を一旦終了する。

次に、トリガー記録処理の手順を説明する。トリガー記録処理は、ＥＣＵ１の動作中において繰り返し実行される処理である。
トリガー記録処理が実行されると、コア１１〜１４は、図３に示すように、まずＳ２１０にて、自コアの補正値最適化トリガーが発生したか否かを判断する。本実施形態では、補正値最適化トリガーは、「タスク抜け」と「処理遅延」である。

なお、コア１１，１２，１３，１４はそれぞれ、ＲＯＭ１５に記憶されているＯＳプログラムを実行することにより、リアルタイムオペレーティングシステム（以下、ＲＴＯＳ）を動作させる。ＲＴＯＳは、タスクの実行を要求するタスク処理要求が発生すると、このタスク処理要求に対応するタスクに予め設定されたタスク優先度に基づき、タスク優先度の高いタスクを優先して実行するようにタスクの実行順を決定するスケジューリングを行う。また、ＲＴＯＳは、自コアの「タスク抜け」及び「処理遅延」等を検出する。

すなわち、Ｓ２１０では、ＲＴＯＳが「タスク抜け」または「処理遅延」を検出した場合に、自コアの補正値最適化トリガーが発生したと判断する。
Ｓ２１０で、自コアの補正値最適化トリガーが発生していないと判断した場合には、トリガー記録処理を一旦終了する。一方、自コアの補正値最適化トリガーが発生したと判断した場合には、Ｓ２２０にて、補正値最適化トリガーの種類と、現時点における自コアの運転状態とを、補正トリガー情報として、自コアのローカルメモリに記録し、トリガー記録処理を一旦終了する。

なお、補正値最適化トリガーの種類は、「タスク抜け」および「処理遅延」の何れか一方である。また、自コアの運転状態とは、自コアが制御する制御対象の状態である。例えば、コア１１の制御対象はエンジンである。そして、エンジンの状態として、「エンジン高回転」、「エンジン中回転」および「エンジン低回転」の３種類が予め設定されている。「エンジン高回転」は、エンジン回転数が４００１［ｒｐｍ］以上となっている状態である。「エンジン中回転」は、エンジン回転数が２０００［ｒｐｍ］以上であり且つ４０００［ｒｐｍ］以下となっている状態である。「エンジン低回転」は、エンジン回転数が１９９９［ｒｐｍ］以下となっている状態である。

また、コア１４の制御対象は電池である。そして、電池の状態として、「充電状態」、「使用状態」および「未使用状態」の３種類が予め設定されている。「充電状態」は、電池が充電されている状態である。「使用状態」は、電池が使用されている状態である。「未使用状態」は、電池が使用されていない状態である。

次に、予測値計算処理の手順を説明する。予測値計算処理は、ＥＣＵ１の動作中において繰り返し実行される処理である。
予測値計算処理が実行されると、コア１１〜１４は、図４に示すように、まずＳ３１０にて、自コアの計算開始フラグがセットされているか否かを判断する。ここで、自コアの計算開始フラグがセットされている場合には、Ｓ３３０に移行する。一方、自コアの計算開始フラグがセットされていない場合には、Ｓ３２０にて、他コアから計算依頼を受信したか否かを判断する。ここで、他コアから計算依頼を受信していない場合には、Ｓ３１０に移行する。一方、他コアから計算依頼を受信した場合には、Ｓ３３０に移行する。

そしてＳ３３０に移行すると、自コアのローカルメモリに設けられたタスクカウンタ（以下、自コアのタスクカウンタ）をインクリメント（すなわち、１加算）する。さらにＳ３４０にて、自コアのローカルメモリに設けられた関数カウンタ（以下、自コアの関数カウンタ）をインクリメントする。なお、ローカルメモリ２１，２２，２３，２４には、タスクカウンタおよび関数カウンタが設けられている。

そしてＳ３５０にて、自コアのタスクカウンタの値をｉとし、自コアの関数カウンタの値をｊとして、自コアのスタック領域に登録されているタスクのうち、ｉ番目に早く登録されたタスク（以下、ｉ番目のタスク）においてｊ番目に早く呼ばれる関数（以下、ｊ番目の関数）のバス負荷期待値を、自コアのローカルメモリから取得する。複数の関数のバス負荷期待値は、ローカルメモリ２１，２２，２３，２４のそれぞれに記憶されている。関数のバス負荷期待値は、関数がバスアクセスする時間を示している。関数のバス負荷期待値は、関数を構成するアセンブラコードのストア命令、ロード命令、ＲＡＭ１６への読み込み及び書き込み、バス１７に接続されているペリフェラルへのアクセス等に必要な時間等により予め算出される。

次にＳ３６０にて、自コアのローカルメモリに設けられた変数であるバス負荷予測値ＰＶに格納されている値と、Ｓ３５０で取得した値とを加算した加算値を、バス負荷予測値ＰＶに格納する。バス負荷予測値ＰＶは、ローカルメモリ２１，２２，２３，２４のそれぞれに設けられている。

そしてＳ３７０にて、ｉ番目のタスクで呼ばれる全ての関数でバス負荷期待値を取得したか否かを判断する。ここで、全ての関数でバス負荷期待値を取得していない場合には、Ｓ３４０に移行する。一方、全ての関数でバス負荷期待値を取得した場合には、Ｓ３８０にて、自コアの関数カウンタをリセット（すなわち、０に設定）する。

さらにＳ３９０にて、自コアのスタック領域に登録されている全てのタスクでバス負荷期待値を取得したか否かを判断する。ここで、全てのタスクでバス負荷期待値を取得していない場合には、Ｓ３３０に移行する。一方、全てのタスクでバス負荷期待値を取得した場合には、Ｓ４００にて、自コアのタスクカウンタをリセットする。

そしてＳ４１０にて、バス負荷予測値を補正する。具体的には、バス負荷予測値ＰＶに格納されている値を、スタック領域に登録されているタスクの数で除算した除算値を、バス負荷予測値ＰＶに格納する。

次にＳ４２０にて、他コアから計算依頼を受信したことによりＳ３３０〜Ｓ４１０の処理が実行されたか否かを判断する。すなわち、他コアから計算依頼を受信したとＳ３２０で判断された場合に、Ｓ４２０で、他コアから計算依頼を受信したことによりＳ３３０〜Ｓ４１０の処理が実行されたと判断される。

ここで、他コアから計算依頼を受信したことによりＳ３３０〜Ｓ４１０の処理が実行されたと判断された場合には、Ｓ４３０にて、上記の完了通知と、バス負荷予測値と、上記の補正トリガー情報とを、計算依頼の送信元となる他コアへ送信する。なお、他コアへ送信されるバス負荷予測値は、バス負荷予測値ＰＶに格納されている値である。また、他コアへ送信される補正トリガー情報は、自コアのローカルメモリに記録されている補正トリガー情報のうち、他コアへ送信されていないものであり且つ直近に記録されたものである。またＳ４３０では、他コアへ送信されていない補正トリガー情報が存在しない場合には、補正トリガー情報の送信を行わない。そして、Ｓ４３０の処理が終了すると、予測値計算処理を一旦終了する。

一方、他コアから計算依頼を受信したことによりＳ３３０〜Ｓ４１０の処理が実行されたのではないと判断された場合には、Ｓ４４０にて、自コアの完了フラグをセットする。さらにＳ４６０にて、計算開始フラグをクリアして、予測値計算処理を一旦終了する。

ここで、バス負荷期待値を算出する具体例を説明する。図５に示すように、コア１４のスタック領域３４にタスク１とタスク２が登録されているとする。また、タスク１では関数Ａ、関数Ｂおよび関数Ｚが呼ばれ、タスク２では関数Ｃが呼ばれるとする。また、ローカルメモリ２４には、関数Ａ，Ｂ，Ｃ，・・・・，Ｚのバス負荷期待値を示すバス負荷期待値表が記憶されているとする。

まず、１番目のタスクであるタスク１において、１番目の関数である関数Ａのバス負荷期待値を、バス負荷期待値表から取得する。関数Ａのバス負荷期待値は１１μｓであるため、バス負荷予測値ＰＶには「１１」が格納される。

また、１番目のタスクであるタスク１において、２番目の関数である関数Ｂのバス負荷期待値を、バス負荷期待値表から取得する。関数Ｂのバス負荷期待値は１５μｓであるため、バス負荷予測値ＰＶには、「１１」と「１５」の加算値として「２６」が格納される。

さらに、１番目のタスクであるタスク１において、３番目の関数である関数Ｚのバス負荷期待値を、バス負荷期待値表から取得する。関数Ｚのバス負荷期待値は１０μｓであるため、バス負荷予測値ＰＶには、「２６」と「１０」の加算値として「３６」が格納される。

次に、２番目のタスクであるタスク２において、１番目の関数である関数Ｃのバス負荷期待値を、バス負荷期待値表から取得する。関数Ｃのバス負荷期待値は３０μｓであるため、バス負荷予測値ＰＶには、「３６」と「３０」の加算値として「６６」が格納される。これにより、全てのタスクでバス負荷期待値を取得したため、バス負荷期待値の計算が完了する。

さらに、スタック領域３４に登録されているタスクの数は「２」であるため、「６６」を「２」で除算した除算値として「３３」がバス負荷予測値ＰＶに格納される。
次に、Ｓ１００で実行される閾値最適化処理の手順を説明する。

閾値最適化処理が実行されると、コア１１〜１４は、図６に示すように、まずＳ５１０にて、自コアのローカルメモリに設けられたコアカウンタ（以下、自コアのコアカウンタ）をインクリメントする。なお、ローカルメモリ２１，２２，２３，２４には、コアカウンタが設けられている。

そしてＳ５２０にて、自コアのコアカウンタの値をｋとし、ｋ番目のコアの補正トリガー情報が自コアのローカルメモリに記録されているか否かを判断する。なお、コア１１，１２，１３，１４はそれぞれ、１，２，３，４番目のコアである。

ここで、ｋ番目のコアの補正トリガー情報が記録されていない場合には、Ｓ５６０に移行する。一方、ｋ番目のコアの補正トリガー情報が記録されている場合には、ｋ番目のコアの補正トリガー情報を自コアのローカルメモリから取得する。

そしてＳ５４０にて、Ｓ５３０で取得した補正トリガー情報と、自コアのローカルメモリに記憶されているｋ番目のコアの補正値表と、自コアのローカルメモリに記憶されている修正値表とに基づいて、後述する閾値を補正するための補正値を修正する。なお、自コアのローカルメモリには、コア１１，１２，１３，１４の上記の補正値表と、上記の修正値表が記憶されている。

補正値表は、対応するコアの運転状態と補正値との対応関係を示す。修正値表は、補正値最適化トリガーの種類と修正値との対応関係を示す。図７では、コア１１，１４の補正値表と、修正値表とを示している。

Ｓ５４０では、具体的には、まず、取得した補正トリガー情報に含まれている補正値最適化トリガーの種類を確認する。そして、確認した補正値最適化トリガーの種類に対応する修正値を修正値表から抽出する。次に、取得した補正トリガー情報に含まれている運転状態を確認する。そして、ｋ番目のコアの補正値表において、確認した運転状態に対応する補正値と、修正値表から抽出した修正値との加算値を、新たな補正値として、確認した運転状態に対応する補正値を修正する。

ここで、コア１４の補正値表における補正値を修正する具体例を説明する。まず、コア１４の補正トリガー情報に含まれている補正値最適化トリガーの種類を確認した結果、補正値最適化トリガーの種類は「処理遅延」であったとする。図７に示すように、修正値表において、「処理遅延」に対応する修正値は「−１」である。このため、修正値表から修正値として「−１」が抽出される。次に、コア１４の補正トリガー情報に含まれている運転状態を確認した結果、運転状態は「充電状態」であったとする。コア１４の補正値表において、「充電状態」に対応する補正値は「−５」である。このため、コア１４の補正値表において、補正値の「−５」と、修正値の「−１」との加算値である「−６」を、「充電状態」に対応する補正値として、コア１４の補正値表の補正値を修正する。

そして、Ｓ５４０の処理が終了すると、図６に示すように、Ｓ５５０において、Ｓ５４０で修正された補正値と、自コアのローカルメモリに記憶されている基本閾値表とに基づいて、ｋ番目のコアの閾値を算出する。なお、コア１１，１２，１３，１４のローカルメモリには、上記の基本閾値表が記憶されている。基本閾値表は、図７に示すように、コアと基本閾値との対応関係を示す。

Ｓ５５０では、具体的には、まず、ｋ番目のコアに対応する基本閾値を基本閾値表から抽出する。そして、基本閾値表から抽出した基本閾値と、Ｓ５４０で算出された補正値との加算値を、ｋ番目のコアの閾値とする。

ここで、コア１４の閾値を算出する具体例を説明する。まず、コア１４に対応する基本閾値を基本閾値表から抽出する。図７に示すように、基本閾値表において、４番目のコアに対応する基本閾値は「３５」である。このため、基本閾値表から抽出した基本閾値の「３５」と、Ｓ５４０で算出された補正値の「−６」との加算値である「２９」が、コア１４の閾値として算出される。したがって、コア１４の閾値は２９［μｓ／タスク］となる。

そして、Ｓ５５０の処理が終了すると、図６に示すように、Ｓ５６０において、全てのコアで閾値が算出されたか否かを判断する。本実施形態では、具体的には、自コアのコアカウンタの値が「４」である場合に、全てのコアで閾値が算出されたと判断する。

ここで、全てのコアで閾値が算出されていない場合には、Ｓ５１０に移行する。一方、全てのコアで閾値が算出された場合には、Ｓ５７０にて、自コアのコアカウンタをリセットして、閾値最適化処理を終了する。

次に、Ｓ１２０で実行される自コアタスク制御処理の手順を説明する。
自コアタスク制御処理が実行されると、コア１１〜１４は、図８に示すように、まずＳ６１０にて、自コアのスタック領域に登録されているタスクの中から、最も優先度が低いタスクを選択する。なお、タスクには、「高優先度」、「中優先度」および「低優先度」のように優先度が設定されている。スタック領域に登録されているタスクは、優先度が高いタスクを優先して順次実行される。

そしてＳ６２０にて、Ｓ６１０で選択したタスクをスタック領域から削除する。さらにＳ６３０にて、バス負荷予測値を修正する。具体的には、バス負荷予測値ＰＶに格納されている値から、Ｓ６１０で選択したタスクのバス負荷予測値を減算した減算値を、バス負荷予測値ＰＶに格納する。

そしてＳ６４０にて、バス負荷予測値ＰＶに格納されている値が、自コアの閾値を超えているか否かを判断する。ここで、バス負荷予測値ＰＶに格納されている値が自コアの閾値を超えている場合には、Ｓ６１０に移行する。一方、バス負荷予測値ＰＶに格納されている値が自コアの閾値以下である場合には、自コアタスク制御処理を終了する。

ここで、バス負荷予測値を修正する具体例を説明する。図５に示すように、コア１４のスタック領域３４にタスク１とタスク２が登録されているとする。また、タスク１は「高優先度」に、タスク２は「中優先度」に設定されているとする。このため、タスク１とタスク２のうち、タスク２がスタック領域３４から削除される。そして、タスク２が削除される前のバス負荷予測値（すなわち、バス負荷予測値ＰＶに格納されている値）は３３［μｓ／タスク］であり、タスク２のバス負荷予測値は１５［μｓ／タスク］である。このため、バス負荷予測値ＰＶには、「３３」から「１５」を減算した減算値として「１８」が格納される。

次に、他コアタスク制御処理の手順を説明する。他コアタスク制御処理は、ＥＣＵ１の動作中において繰り返し実行される処理である。
他コアタスク制御処理が実行されると、コア１１〜１４は、図９に示すように、まずＳ７１０にて、他コアからタスク制御依頼を受信したか否かを判断する。ここで、タスク制御依頼を受信していない場合には、他コアタスク制御処理を一旦終了する。一方、タスク制御依頼を受信した場合には、Ｓ７２０にて、Ｓ６１０と同様にして、自コアのスタック領域に登録されているタスクの中から、最も優先度が低いタスクを選択する。

そしてＳ７３０にて、Ｓ７２０で選択したタスクをスタック領域から削除する。さらにＳ７４０にて、Ｓ６３０と同様にして、バス負荷予測値を修正する。
そしてＳ７５０にて、Ｓ６４０と同様にして、バス負荷予測値ＰＶに格納されている値が、タスク制御依頼とともに受信された自コアの閾値を超えているか否かを判断する。ここで、バス負荷予測値ＰＶに格納されている値が自コアの閾値を超えている場合には、Ｓ７２０に移行する。一方、バス負荷予測値ＰＶに格納されている値が自コアの閾値以下である場合には、他コアタスク制御処理を一旦終了する。

次に、コア１１〜１４の動作の具体例を説明する。
図１０に示すように、まず、コア１１で演算イベントが発生することにより、コア１１は、計算依頼をコア１２，１３，１４へ送信する処理Ｐ１１を実行する。矢印Ｌ１，Ｌ２，Ｌ３はそれぞれ、コア１１がコア１２，１３，１４へ計算依頼を送信することを示す。

コア１１は、計算依頼を送信した後に、バス負荷期待値を計算する処理Ｐ１２を実行する。処理Ｐ１２では、バス負荷期待値の計算が完了すると、コア１１の完了フラグをセットする。

また、計算依頼を受信したコア１２，１３，１４はそれぞれ、バス負荷期待値を計算する処理Ｐ２１，Ｐ３１，Ｐ４１を実行する。処理Ｐ２１，Ｐ３１，Ｐ４１では、バス負荷期待値の計算が完了すると、完了通知と、バス負荷予測値と、補正トリガー情報とをコア１１へ送信する。矢印Ｌ１１，Ｌ１２，Ｌ１３はそれぞれ、コア１２，１３，１４がコア１１へ完了通知等を送信することを示す。

コア１１は、コア１２，１３，１４から完了通知等を受信すると、それぞれコア１２，１３，１４の完了フラグをセットする処理Ｐ１３，Ｐ１４，Ｐ１５を実行する。処理Ｐ１３，Ｐ１４，Ｐ１５では、さらに、完了通知とともに受信されたバス負荷期待値および補正トリガー情報をローカルメモリ２１に記録する。

全コアにおいて完了フラグがセットされると、コア１１は、コア１１，１２，１３，１４それぞれの閾値を算出する処理Ｐ１６を実行する。処理Ｐ１６では、全コアにおいて閾値の算出が完了すると、タスク制御依頼と、算出された閾値とを、コア１２，１３，１４へ送信する。矢印Ｌ２１，Ｌ２２，Ｌ２３はそれぞれ、コア１１がコア１２，１３，１４へタスク制御依頼等を送信することを示す。

コア１１は、タスク制御依頼等を送信した後に、コア１１におけるバス負荷期待値が閾値を超えないようにタスクを制御する処理Ｐ１７を実行する。
また、タスク制御依頼等を受信したコア１２，１３，１４はそれぞれ、コア１２，１３，１４におけるバス負荷期待値が閾値を超えないようにタスクを制御する処理Ｐ２２，Ｐ３２，Ｐ４２を実行する。

またコア１１は、処理Ｐ１７が終了すると、コア１１，１２，１３，１４の完了フラグをクリアする処理Ｐ１８を実行する。
このように構成されたＥＣＵ１は、コア１１，１２，１３，１４と、ＲＡＭ１６と、バス１７と、スタック領域３１，３２，３３，３４とを備える。

ＲＡＭ１６は、コア１１，１２，１３，１４のそれぞれがアクセス可能である。バス１７は、コア１１，１２，１３，１４とＲＡＭ１６との間をデータの入出力が可能となるように接続する。スタック領域３１，３２，３３，３４は、コア１１，１２，１３，１４のそれぞれに対応して設けられ、対応するコアが実行する１つ又は複数のタスクが登録される。

ＥＣＵ１は、コア１１，１２，１３，１４のそれぞれについて、スタック領域３１，３２，３３，３４に登録されていているタスクによりバス１７を介してＲＡＭ１６へアクセスするときにバス１７に掛かるバス負荷の度合いを予測したバス負荷予測値を算出する。

ＥＣＵ１は、コア１１，１２，１３，１４のそれぞれについて、車両のエンジン、モータ、ＣＡＮ通信および電池の状態に基づいて、バス負荷の許容値を示す閾値を算出する。
ＥＣＵ１は、コア１１，１２，１３，１４のそれぞれについて、バス負荷予測値が閾値を超えないように、スタック領域３１，３２，３３，３４に登録されているタスクをスタック領域３１，３２，３３，３４から削除する。

このようにＥＣＵ１は、車両の状態に基づいてバス負荷閾値を算出するため、車両の状態に応じてバス負荷閾値を変更することができる。
例えば、車両のエンジンおよび電池の状態に応じて、それぞれコア１１およびコア１４がＲＡＭ１６へアクセスする頻度は変化する。

コア１１とコア１４の両方でＲＡＭ１６へアクセスする頻度が多い場合には、コア１１とコア１４の両方でＲＡＭ１６へアクセスすることができるように、コア１１とコア１４との両方で、ＲＡＭ１６へのアクセスを制限する必要がある。一方、コア１１でＲＡＭ１６へアクセスする頻度が多く、コア１４でＲＡＭ１６へアクセスする頻度が少ない場合には、コア１１でＲＡＭ１６へのアクセスを制限しなくても、コア１４におけるタスク処理に影響を及ぼさない場合もある。逆に、コア１１でＲＡＭ１６へのアクセスを制限すると、ＥＣＵ１の処理効率を無駄に低下させてしまう恐れがある。

これに対し、ＥＣＵ１は、コア１１でＲＡＭ１６へアクセスする頻度が多く、第２コアでＲＡＭ１６へアクセスする頻度が少ない場合には、コア１１の閾値を大きくして、ＲＡＭ１６へのアクセス制限を緩和することができる。これにより、コア１１によるＲＡＭ１６へのアクセスを無駄に制限することがなくなる。

このようにＥＣＵ１は、車両の状態に応じてバス１７に掛かる負荷が変化することに起因して発生する処理への影響を必要最小限に抑制するとともに、ＥＣＵ１全体としての処理効率の低下を抑制することができる。

また車両には、制御対象として、エンジン、モータ、ＣＡＮ通信および電池が搭載され、コア１１，１２，１３，１４のそれぞれは、エンジン、モータ、ＣＡＮ通信および電池を制御するためのタスクを実行するように構成される。そしてＥＣＵ１は、コア１１，１２，１３，１４のそれぞれについて、エンジン、モータ、ＣＡＮ通信および電池の状態に基づいて、閾値を算出する。これにより、ＥＣＵ１は、エンジン、モータ、ＣＡＮ通信および電池の状態に応じてバス１７に掛かる負荷が変化することに起因して発生する処理への影響を必要最小限に抑制するとともに、ＥＣＵ１全体としての処理効率の低下を抑制することができる。

またＥＣＵ１は、「スタック領域の使用率が予め設定された一定値を超えること」と、「バス１７を長期占有する関数として予め設定された長期占有関数を含むタスクがスタック領域に登録されること」のように、ソフトウェアによって実行される処理により判断されるものを、演算イベントとした。これらの演算イベントは、コア１１，１２，１３，１４がバス１７をどの程度使用するかを明確に判断することができるため、バス負荷予測値の計算を開始するための精度のよいトリガーとすることができる。

またＥＣＵ１は、バス負荷予測値が閾値を超えている場合に、スタック領域に登録されているタスクの中から、最も優先度が低いタスクを削除する。これにより、ＥＣＵ１は、タスクが実行されなくなることに起因して車両に及ぼす影響を最小限に抑えることができる。

またＥＣＵ１は、スタック領域に登録されているタスクで呼ばれる関数のバス負荷期待値を用いて、スタック領域に登録されている全タスクのバス負荷期待値を算出する。関数がバスアクセスする時間の理論値は、関数を構成するアセンブラコードから計算可能である。このため、バス負荷期待値を正確に算出することができる。

以上説明した実施形態において、ＥＣＵ１は電子制御装置に相当し、ＲＡＭ１６は共有メモリに相当し、Ｓ３３０〜Ｓ４１０は負荷予測部としての処理に相当し、Ｓ５１０〜Ｓ５７０は閾値算出部としての処理に相当、Ｓ６１０〜Ｓ６４０，Ｓ７２０〜Ｓ７５０はタスク削除部としての処理に相当する。

また、閾値はバス負荷閾値に相当し、車両のエンジン、モータ、ＣＡＮ通信および電池は制御対象に相当する。
以上、本開示の一実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。

［変形例１］
例えば上記実施形態では、演算イベントとして、「各コアで実行予定のタスクを登録するスタック領域の使用率が予め設定された一定値を超えること」であるものを示した。しかし、スタック領域の使用率の代わりに、スタック領域に登録されているタスクの数を用いてもよい。例えば、スタック領域に登録可能な全タスク数が８である場合において、スタック領域に登録されているタスクの数が６以上であることを演算イベントとするようにしてもよい。これにより、演算イベントが発生したか否かを簡便な方法で判断することができる。

［変形例２］
上記実施形態では、「スタック領域の使用率が予め設定された一定値を超えること」などのように、ソフトウェアによって実行される処理により判断されるものを、演算イベントとした。しかし、ドアの開閉、ライトのオン／オフ、カーナビ等のアクセサリ起動などのように、車両に搭載されたハードウェアの状態を、演算イベントとしてもよい。これにより、演算イベントが発生したか否かを、オンであるかオフであるかという簡便な方法で判断することができる。

［変形例３］
上記実施形態では、バス負荷予測値が閾値を超えている場合に、スタック領域に登録されているタスクの中から、最も優先度が低いタスクを削除するものを示した。しかし、最も優先度が低いタスクが２つ以上存在する場合には、タスクで呼ばれる関数の優先度が最も低いタスクを選択するようにするとよい。これにより、ＥＣＵ１は、削除した場合に車両への影響が小さい方のタスクを選択することができる。

［変形例４］
上記実施形態では、演算イベントが発生したコアで閾値を算出する処理を実行するものを示した。しかし、計算資源に余裕があるコアで、閾値を算出する処理を実行させるようにしてもよい。これにより、演算イベントが発生したコアで、負荷が高くなってしまう事態の発生を抑制することができる。また、複数のコアが同性能でなく、高性能のコアと低性能のコアとを組み合わせた場合に、閾値を算出する処理を高性能のコアで実行させるようにしてもよい。

また、上記実施形態における１つの構成要素が有する機能を複数の構成要素に分担させたり、複数の構成要素が有する機能を１つの構成要素に発揮させたりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。

上述したＥＣＵ１の他、当該ＥＣＵ１を構成要素とするシステム、当該ＥＣＵ１としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体、車両制御方法など、種々の形態で本開示を実現することもできる。

１…ＥＣＵ、２…マイコン、１１，１２，１３，１４…コア、１６…ＲＡＭ、１７…バス、３１，３２，３３，３４…スタック領域

Claims (2)

1. 車両を制御する電子制御装置（１）であって、
   複数のコア（１１，１２，１３，１４）と、
   複数の前記コアのそれぞれがアクセス可能な共有メモリ（１６）と、
   複数の前記コアと前記共有メモリとの間をデータの入出力が可能となるように接続するバス（１７）と、
   複数の前記コアのそれぞれに対応して設けられ、対応する前記コアが実行する１つ又は複数のタスクが登録されるスタック領域（３１，３２，３３，３４）と、
   複数の前記コアのそれぞれについて、前記スタック領域に登録されていている前記タスクにより前記バスを介して前記共有メモリへアクセスするときに前記バスに掛かるバス負荷の度合いを予測したバス負荷予測値を算出するように構成された負荷予測部（Ｓ３３０〜Ｓ４１０）と、
   複数の前記コアのそれぞれについて、前記車両の状態に基づいて、前記バス負荷の許容値を示すバス負荷閾値を算出するように構成された閾値算出部（Ｓ５１０〜Ｓ５７０）と、
   複数の前記コアのそれぞれについて、前記バス負荷予測値が前記バス負荷閾値を超えないように、前記コアに対応した前記スタック領域に登録されている前記タスクを前記スタック領域から削除するように構成されたタスク削除部（Ｓ６１０〜Ｓ６４０，Ｓ７２０〜Ｓ７５０）と
   を備える電子制御装置。
2. 請求項１に記載の電子制御装置であって、
   前記車両には、複数の制御対象が搭載され、
   複数の前記コアのそれぞれは、互いに異なる前記制御対象を制御するための前記タスクを実行するように構成され、
   前記閾値算出部は、複数の前記コアのそれぞれについて、前記コアに対応する前記制御対象の状態を、前記車両の状態として、前記バス負荷閾値を算出する電子制御装置。

Images