IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日立オートモティブシステムズ株式会社の特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-16
(45)【発行日】2024-12-24
(54)【発明の名称】車両制御装置
(51)【国際特許分類】
   G06F 11/20 20060101AFI20241217BHJP
   G06F 9/50 20060101ALI20241217BHJP
   G06F 9/48 20060101ALI20241217BHJP
   B60R 16/02 20060101ALI20241217BHJP
【FI】
G06F11/20 630
G06F9/50 120Z
G06F9/48 300D
G06F9/50 120B
B60R16/02 660G
【請求項の数】 9
(21)【出願番号】P 2020211436
(22)【出願日】2020-12-21
(65)【公開番号】P2022098090
(43)【公開日】2022-07-01
【審査請求日】2023-07-05
(73)【特許権者】
【識別番号】509186579
【氏名又は名称】日立Astemo株式会社
(74)【代理人】
【識別番号】110001829
【氏名又は名称】弁理士法人開知
(72)【発明者】
【氏名】石郷岡 祐
(72)【発明者】
【氏名】芹沢 一
(72)【発明者】
【氏名】村上 隆
【審査官】田中 幸雄
(56)【参考文献】
【文献】特開2006-134203(JP,A)
【文献】特開2012-032888(JP,A)
【文献】特許第6189004(JP,B1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 11/20
G06F 9/50
G06F 9/48
B60R 16/02
(57)【特許請求の範囲】
【請求項1】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、前記故障した前記コアの前記タスクが属する車両の機能グループが前記故障していない前記コアの前記タスクが属する前記車両の機能グループに属する場合、前記タスクの実行時間の余裕時間であるマージンを特定の前記タスクに集結させることを特徴とする車両制御装置。
【請求項2】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
車両の機能グループが1つ以上の前記タスクからなるタスクグループで構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクで構成され、前記制御処理タスクは前記入力処理タスクの後で実行され、前記出力処理タスクの前で実行され、少なくとも前記出力処理タスクは時分割実行されることを特徴とする車両制御装置。
【請求項3】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し
車両の機能グループが1つ以上の前記タスクからなるタスクグループで構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクで構成され、前記制御処理タスクは前記入力処理タスクの後で実行され、前記出力処理タスクの前で実行され、少なくとも前記出力処理タスクは時分割実行され、
前記タスクには先に実行する順番を決定する優先度が与えられ、前記優先度が与えられた前記タスク、特定の時刻で特定の処理を実行する優先度スケジューラを備えることを特徴とする車両制御装置。
【請求項4】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
車両の機能グループが1つ以上の前記タスクからなるタスクグループで構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクで構成され、前記制御処理タスクは前記入力処理タスクの後で実行され、前記出力処理タスクの前で実行され、少なくとも前記出力処理タスクは時分割実行され、
前記実行タイミング調停部は、
前記タスクグループの実行時刻を、前記入力処理タスク、前記制御処理タスク及び前記出力処理タスクの実行順序を保ちつつ、変更することを特徴とする車両制御装置。
【請求項5】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
車両の機能グループが1つ以上の前記タスクからなるタスクグループで構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクで構成され、前記制御処理タスクは前記入力処理タスクの後で実行され、前記出力処理タスクの前で実行され、少なくとも前記出力処理タスクは時分割実行され、
前記実行タイミング調停部は、
同一周期にて、前記出力処理タスクの実行までに、前記入力処理タスク及び前記制御処理タスクが終了する時間を、移動可能か否かを判定し、移動できない場合には、縮退制御の通知またはエラー通知を行うことを特徴とする車両制御装置。
【請求項6】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
車両の機能グループが、1つ以上の前記タスクからなるタスクグループにより構成され、前記実行タイミング調停部は、複数の前記機能グループの前記タスクグループが同一の前記コアに存在する場合には、前記タスクの実行時間の余裕時間であるマージンを前記機能グループの数で割り、前記タスクグループと前記タスクを開始する開始時間とを有するスケジューリングテーブルを作成することを特徴とする車両制御装置。
【請求項7】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
車両の機能グループが、1つ以上の前記タスクからなるタスクグループにより構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクにより構成され、前記制御処理タスクと前記出力処理タスクの実行タイミングは不連続であることを特徴とする車両制御装置。
【請求項8】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、を備え、
前記実行タイミング調停部は、
前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、
前記コアは複数個であり、前記複数個の前記コアの故障個所を出力するコンフィグ生成部と、前記コンフィグ生成部が生成した前記複数個の前記コアの故障個所に基づいたタスクセット情報を格納するスケジューラと、を備え、
前記スケジューラは、
前記故障検知部が、前記コアの故障を検知すると、前記スケジューラに格納された前記タスクセット情報から前記故障した前記コアに対応する前記タスクセット情報を選定することを特徴とする車両制御装置。
【請求項9】
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、
前記CPUのコアの故障を検知する故障検知部と、
故障した前記コアが実行していた前記タスクを故障していない前記コアに割り当てる実行タイミング調停部と、
を備え、
前記実行タイミング調停部は、
前記故障していない前記コアが、前記故障した前記コアが実行していた前記タスクが前記故障した前記コアにおいて割り当てられていた時刻で前記故障した前記コアが実行していた前記タスクを実行できるか否か、を検証し、
前記故障していない前記コアにおいて前記時刻に実行される他の前記タスクが存在するとき、前記故障した前記コアが実行していた前記タスクの実行時刻を変更し、前記複数のタスクが実行可能な時刻を設定することを特徴とする車両制御装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のCPUを有する車両制御装置に関する。
【背景技術】
【0002】
自動車制御システムは複数の電子制御ユニット(ECU)で構成される。ECUは厳しい時間制約(デッドライン)を満たすように、センサの入力処理、制御処理の目標値算出処理、アクチュエータの制御処理を実行する必要がある。低コスト化や省スペース化のためにECUの統合が進み、要求計算量の増加に対応したマルチコアが採用されている。
【0003】
しかしながら、制御処理を実行しているコアに故障が発生した場合には、処理の継続実行が不可能となってしまうために、安全保証のためにECU全体を停止する縮退制御が実行される。
【0004】
従って、制御処理を継続実行可能な可用性を向上させる技術が求められる。
特許文献1記載の技術によると、ソフトウェアを実行するコアを定義した設定情報(コア割当情報)を予め動作モードに対応付けて保存し、コア故障検知時にはリセットをトリガに、正常動作可能なコアのみで実行できる動作モードに切り替えることで、ソフトウェアを実行するコアを変更し、可用性を向上できる。
【先行技術文献】
【特許文献】
【0005】
【文献】特開2018-112977号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、特許文献1に記載の技術では、コア移動後のソフトウェアがリアルタイム性を保証して実行可能であることが保証できていない。また、予め設計する必要があるために、ソフトウェア更新に対応することが難しい。
本発明は、上記のような課題を解決するためになされたものであり、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
上記課題を解決するため、本発明は次のように構成される。
複数のタスクを時刻同期で実行するCPUを有する車両制御装置であって、 前記CPUのコアの故障を検知する故障検知部と、故障した前記コアが実行していたタスクを故障していない前記コアに割り当てる実行タイミング調停部と、を備え、前記実行タイミング調停部は、前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を変更し、前記複数の前記タスクが実行可能な時刻を設定し、前記故障した前記コアの前記タスクが属する車両の機能グループが前記故障していない前記コアの前記タスクが属する前記車両の機能グループに属する場合、前記タスクの実行時間の余裕時間であるマージンを特定の前記タスクに集結させる。

【発明の効果】
【0008】
本発明に係る車両制御装置によれば、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することができる。
【図面の簡単な説明】
【0009】
図1】実施例1、2、3及び4に係る車両制御装置の構成図である。
図2】実施例1、2及び3に係る車両制御装置の機能ブロック図である。
図3A】実施例1に係るタスクセット情報を示す図である。
図3B】実施例1に係るタスクセット情報を示す図である。
図3C】実施例1に係るタスクセット情報を示す図である。
図4】実施例1に係る処理継続判定表を示す図である。
図5】実施例1に係るコア割当情報を示す図である。
図6A】実施例1に係るスケジューリングテーブルを示す図である。
図6B】実施例1に係るスケジューリングテーブルを示す図である。
図7】実施例1に係る継続処理判定部の処理フローチャートである。
図8】実施例1に係るコア割当更新部の処理フローチャートである。
図9】実施例1に係る実行タイミング調停部の処理フローチャートである。
図10A】実施例2に係るタスクセット情報を示す図である。
図10B】実施例2に係るタスクセット情報を示す図である。
図10C】実施例2に係るタスクセット情報を示す図である。
図11A】実施例2に係るスケジューリングテーブルを示す図である。
図11B】実施例2に係るスケジューリングテーブルを示す図である。
図12】実施例2に係る実行タイミング調停部の処理フローチャートである。
図13A】実施例3に係るタスクセット情報を示す図である。
図13B】実施例3に係るタスクセット情報を示す図である。
図13C】実施例3に係るタスクセット情報を示す図である。
図14】実施例3に係る処理継続判定表を示す図である。
図15】実施例3にコア割当情報を示す図である。
図16A】実施例3に係るスケジューリングテーブルを示す図である。
図16B】実施例3に係るスケジューリングテーブルを示す図である。
図17】実施例3に係る実行タイミング調停部の処理フローチャートである。
図18】実施例4に係る制御システムの機能ブロック図である。
図19】実施例5に係るシステムの構成図である。
図20】実施例5に係る制御システムの機能ブロック図である。
図21A】実施例5に係るタスクセット情報を示す図である。
図21B】実施例5に係るタスクセット情報を示す図である。
図21C】実施例5に係るタスクセット情報を示す図である。
図22】実施例5に係る処理継続判定表を示す図である。
図23】実施例5にコア割当情報を示す図である。
図24A】実施例5に係るスケジューリングテーブルを示す図である。
図24B】実施例5に係るスケジューリングテーブルを示す図である。
【発明を実施するための形態】
【0010】
本発明に係る車両制御装置は、制御ソフトウェアを実行するコアの故障を検出し、故障したコアによって影響をうける処理において継続実行すべき処理を選択し、継続実行すべき処理を動作させるコアを決定する。
【0011】
また、継続実行すべき処理の追加によって生じる実行タイミングの競合を判定し、調停する。調停後のタイミングで車両制御装置を動作させる。
【0012】
以下、図面を用いて本発明の実施の形態について説明する。
<実施例1>
図1は、本発明の実施例1に係るシステムの構成図を示す図である。車両制御装置0は、ECU1とネットワーク2で構成される。ECU1は複数のCPU11とメモリ12で構成される。複数のCPU11は、タスクを時刻同期で実行する。CPU11のそれぞれが複数のコア10から構成される場合があるので、CPU単体であってもマルチコアである可能性があり、本発明の対象となるが、本実施例1では1つのCPUが1つのコア10を有する。ECU1には、CPU11が複数存在するので、ECU1には、複数個のコア10が配置されている。メモリ12にはプログラムが保存される。メモリ12の個数は問わない。
【0013】
図2は、実施例1に係るECU1の機能ブロック図を示す。ECU1の故障検知部121はコア10の故障を検知し、継続処理選定部122に故障箇所を通知する。継続処理選定部122は継続処理の対象となるタスクグループをコア割当更新部123に通知する。本実施例1では、ソフトウェア処理を実行する単位をタスクと呼ぶ。タスクはオペレーティングシステム(OS)が管理する実行管理対象であり、スレッドと同様である。
【0014】
制御ソフトウェアの処理はタスクの中で実行されるため、1つのタスクのなかで複数の制御ソフトウェア処理を実行することもできる。コア割当更新部123は割当コアを選定し、前記タスクグループと共に実行タイミング調停部124に通知する。
【0015】
実行タイミング調停部124は、新たに割り当てられた前記タスクグループと、本来割り当てられていたタスクグループの間の実行タイミング競合を検出する。つまり、故障したコア10が実行していたタスクを故障していないコア10が同時刻で実行できるか否かを検証する。そして、コア10のタスクの実行タイミング(実行時刻)を変更する(移動する)ことで調停する。実行時刻の変更は、コア10の入出力時間制約が供される範囲で行う。実行タイミング調停部124は、故障していたコア10の複数のタスクが独立して実行可能な時刻を設定し、調停されたタスクセット情報とする。調停されたタスクセット情報はスケジューラ127に通知される。スケジューラ127はタスクセット情報に基づいて、時分割でタスクを実行する。スケジューラ127は、時刻同期で実行するタスクを制御し、特定の時刻で特定のタスクを実行する。調停ができなかった場合には、縮退制御部125を実行し、エラー通知部126が、エラーを他のECUにネットワーク経由で通知する。
【0016】
図3A図3B図3Cは実施例1に係るタスクセット情報131、132、133を示す図である。タスクセット情報はコアID、タスクグループ、タスクID、性質、周期、開始時間、終了時間、マージンから構成される。
【0017】
コアIDとはCPU11を識別するIDである。タスクグループとは制御ソフトウェアの集合を示し、値はタスクグループIDを示す。タスクIDとはタスクを識別するIDを示す。性質とはタスクの役割を示す。Rはタスクグループへの入力処理を実施する(Copy-In)入力処理タスクであることを示し、Eは制御処理を実行する制御処理タスクであることを示し、WはEで算出した制御処理の結果を出力する(Copy-Out)出力処理タスクであることを示す。
【0018】
周期はタスクが実行される間隔を示す。開始時間はタスクが実行を開始する時間であり、単位はmsである。終了時間はタスクが終了する時間であり、単位はmsである。マージンはタスクの実行時間が変動する可能性を考慮して設けられた余裕時間(タスクの実行時間の余裕時間)であり、マージンの時間だけ終了時間が長く設定されている。単位はmsである。
【0019】
図3A)はコア故障発生前のタスクセット情報131であり、図3Bはコア割当先を決定したが調停前のタスクセット情報132であり、図3Cは調停後のタスクセット情報133を示す。
【0020】
図4は実施例1に係る処理継続判定表134を示す。処理継続判定表134は機能グループ、タスクグループ、タスクID、処理継続、ASIL、要求CPU使用率から構成される。機能グループとは、車両制御機能のまとまりを示し、値は機能グループIDを示す。例えば、エンジンを制御するソフトウェアのグループや、運転支援システムや自動運転のための目標操舵角度や加減速指令を計算するソフトウェアのグループである。
【0021】
タスクグループは機能グループを実現する1つ以上のタスクの集合であり、値はタスクグループIDを示す。1つの機能グループは1つ以上のタスクからなるタスクグループで構成される。また、1つのタスクグループはR、E、Wで構成され、少なくとも出力処理タスクは時分割で実行される。EはRの後で実行され、Wの前で実行される。タスクIDとはタスクを識別するIDを示す。処理継続とは、コア故障時にタスクグループの処理を継続するか否かを示す。「必要」とは処理を継続する必要があることを示し、「不必要」は処理を継続する必要がないことを示す。ASILとは機能安全規格ISO262626で定義されたAutomotive Safety Integrity Levelの略で、求められる自動車安全水準を示す。QM、A~Dでレベル付けされ、Dほど要求水準が高いことを意味する。要求CPU使用率とは、タスクグループを実行するときに消費するCPU使用率を意味する。
【0022】
図5は実施例1に係るコア割当情報135を示す。コア割当情報135はコアID、ASIL,実行機能グループ、CPU使用率、マージン、CPU使用可能率から構成される。コアIDとはCPU11を識別するIDである。ASILとはコアが準拠するASILを示す。実行機能グループとは、コア10が実行する機能グループを示し、値は機能グループIDを示す。
【0023】
CPU使用率とは前記実行機能グループを実行するときに消費するCPU負荷を意味する。マージンとはタスクグループの実行時間が予測から乖離したときにもリアルタイム性を保証するために要した時間的な余裕のことを意味する。CPU使用可能率とは、前記CPU使用率と前記マージンを除いた他のタスクグループを実行可能な程度を示す。
【0024】
図6A図6Bは実施例1に係るスケジューリングテーブル136、137を示す。スケジューリングテーブルはタスクグループと開始時間から構成される。タスクグループとは、特定のコアで実行されるタスクグループIDを示す。開始時間とは特定の時間に実行されるタスクIDを示す。図6Aは調停前のスケジューリングテーブル136を示し、図6Bは調停後のスケジューリングテーブル137を示す。
【0025】
以降より、実施例1に係る動作フローの詳細を説明する。
【0026】
図7は継続処理判定部122の処理フローである。以下、図7の各ステップについて説明する。
【0027】
図7:ステップ1221)
継続処理選定部122は故障箇所(コアID)に基づいてタスクセット情報から影響を受けるタスクグループを特定する。具体的にはタスクセット情報131からコアIDで実行されているタスクグループを特定する。
【0028】
図7:ステップ1222)
継続処理選定部122は特定した前記タスクグループから、処理継続判定表134に基づいて、前記タスクグループの停止によって影響を受ける機能グループを特定する。このステップ1222においては、処理継続判定表134に基づき、故障したコア10に応じて影響を受ける機能グループが自動車安全水準に基づいて、特定される。
【0029】
図7:ステップ1223)
継続処理選定部122は、処理継続判定表134に基づいて、特定した機能グループのなかで、処理継続が必要となるタスクグループを特定する。
【0030】
図8はコア割当更新部123の処理フローチャートである。以下、図8の各ステップについて説明する。
【0031】
図8:ステップ1231)
コア割当更新部123は、前記タスクグループの移動先を探すために、コア割当情報135を参照し、CPU使用可能率が前記タスクグループの要求CPU使用率も大きいコアIDを見つける。
【0032】
図8:ステップ1232)
コア割当更新部123は、ステップ1231で見つけた前記コアIDが故障を検知したECUと同じECUであるか否かを判定する。真である場合には本処理フローを終了し、偽である場合にはステップ1233に進む。
【0033】
図8:ステップ1233)
コア割当更新部123は、ステップ1231で見つけたコアIDを有するECUに、割当コアIDとECUに処理継続が必要なタスクグループ情報を送付する。
【0034】
図9は実行タイミング調停部124の処理フローチャートである。以下、図9の各ステップについて説明する。
【0035】
図9:ステップ12401)
実行タイミング調停部124は、処理継続が必要な前記タスクグループを、前記割当コアIDに追加するようにタスクセット情報を更新し、タスクセット情報132を作成する(図3B)。
【0036】
図9:ステップ12402)
実行タイミング調停部124は、前記割当コアIDに複数の機能グループが存在する場合には、マージンを機能グループ数で割る(図3B)。
【0037】
図9:ステップ12403)
実行タイミング調停部124は、ハイパーピリオドに基づいてスケジューリングテーブル(図6A)を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。
【0038】
図9:ステップ12404)
実行タイミング調停部124は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのRで発生したか否かを判定する。真である場合にはステップ12405に進み、偽である場合にはステップ12406に進む。
【0039】
図9:ステップ12405)
実行タイミング調停部124は、処理継続が必要な前記タスクグループのRを開始時間が早く、かつ、空いている時間に移動する。
【0040】
図9:ステップ12406)
実行タイミング調停部124は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのEで発生したか否かを判定する。真である場合にはステップ12407に進み、偽である場合にはステップ12408に進む。
【0041】
図9:ステップ12407)
実行タイミング調停部124は、処理継続が必要な前記タスクグループのEを開始時間が早く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、EはRよりも遅い時間に実行される。
【0042】
図9:ステップ12408)
実行タイミング調停部124は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのWで発生したか否かを判定する。真である場合にはステップ12409に進み、偽である場合にはステップ12410に進む。
【0043】
図9:ステップ12409)
実行タイミング調停部124は、処理継続が必要な前記タスクグループのWを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、WはEよりも遅い時間に実行される。EとWの時間は離れていてもよい。Eは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のようにEとWが離れることによって、Wの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。実行タイミング調停部124は、タスクグループの実行タイミングを、入力処理タスク、制御処理タスク及び出力処理タスクの実行順序を保ちつつ、変更(移動)して、実行タイミングを調停する。
【0044】
図9:ステップ12410)
実行タイミング調停部124は、W、E、Rのタスクが空いている開始時間に移動できたか否かを判断する。真である場合には本動作フローを終了し、偽である場合にはステップ12411に進む。
【0045】
図9:ステップ12411)
実行タイミング調停部124は、エラー情報をエラー通知部126経由でネットワーク2に送付し、縮退制御部125に縮退制御の実行を通知し、本動作フローを終了する。
【0046】
以上のように、実行タイミング調停部124は、同一周期にて、出力タスクの実行までに入力処理タスクRと制御処理タスクEを、移動可能か否かを判定し、移動でいない場合は、エラーを通知し縮退制御が行われる。なお、ステップ12411においては、エラー通知または縮退制御の通知を行うこととしてもよい。本実施例1によると、コア故障が発生しても処理継続が必要なタスクが別のコアで実行が可能となるために可用性が向上する。
【0047】
また、本実施例1によると、処理継続が必要なタスクが別のコアで実行する場合に、処理の実行タイミング競合が発生しても、実行順序を守りつつ、空き時間に実行タイミングを変更するために、制御演算結果に影響を出さず、かつ、デッドラインを保証できる。
【0048】
また、本実施例1によると、処理の実行タイミングに競合が発生した場合に、処理継続が必要なタスクの実行時間を変更し、元々実行していたタスクに影響を与えないために、リアルタイム性の影響を与える範囲を局所化できる。
【0049】
また、本実施例1によると、EのタスクとWのタスクが分離され、時間が空いているために、Eのタスクが予測時間より長く実行されたとしてもマージンで吸収され、Wのタスクの実行時間には影響を与えない。従って、検証範囲を局所化することができる。
【0050】
本実施例1によれば、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することができる。 なお、本実施例1によると、タスクは実行可能なタイミングを時刻で管理された時分割スケジューリングに基づいて実装されているが、これに限らない。
【0051】
<実施例2>
実施例2は本発明を優先度スケジューリングで実現する例である。実施例1との差分のみに絞って説明する。
【0052】
図10は実施例2に係るタスクセット情報231、232、233を示す。タスクセット情報はコアID、タスクグループ、タスクID、性質、周期、優先度、開始時間、実行時間、マージンから構成される。コアID、タスクグループ、タスクID、性質、周期、開始時間、マージンは実施例1と同様である。優先度とは、複数のタスクが実行可能状態である場合に、先に実行する順番を決定するための数字で、数字が小さいほど優先度が高い。実行時間とは、タスクが実行に要する時間である。実行時間は設計時に規定した予測に基づいた値で規定されるが、出荷後に想定よりも大きくなる可能性を見越してマージンが設けられている。実行時間にはマージンの時間を含んでいない。同じタスクグループのRとEは同じ優先度としているがこれに限らない。Rの後にEが実行されるようになっていれば変更可能である。一方、WはRやEよりも優先度を高く設定する。これは出力タイミングを固定にすることで、他からの影響を受けないようにし、検証する範囲を局所化するためである。
【0053】
図11A図11Bは実施例2に係るスケジューリングテーブル236、237を示す。スケジューリングテーブルはタスクグループと開始時間から構成され、タスクグループと開始時間は実施例1と同じ意味を持つ。
【0054】
図12は実施例2に係る実行タイミング調停部224の処理フローである。以下、図12の各ステップについて説明する。
【0055】
図12:ステップ2241)
実行タイミング調停部124は、処理継続が必要な前記タスクグループを、前記割当コアIDに追加するようにタスクセット情報を更新し、タスクセット情報232を作成する(図10B)。
【0056】
図12:ステップ2242)
実行タイミング調停部124は、同一の前記コアIDに複数の機能グループが存在する場合には、マージンを機能グループ数で割る(図10B)。
【0057】
図12:ステップ2243)
実行タイミング調停部124は、ハイパーピリオドに基づいてスケジューリングテーブル(図11A)を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。
【0058】
図12:ステップ2244)
実行タイミング調停部124は、同じ時刻に実行されるのタスクがある場合、それは処理継続が必要な前記タスクグループのWで発生したか否かを判定する。真である場合にはステップ2245に進み、偽である場合にはステップ2246に進む。
【0059】
図12:ステップ2445)
実行タイミング調停部124は、処理継続が必要な前記タスクグループのWを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、WはEよりも遅い時間に実行される。EとWの時間は離れていてもよい。Eは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のように、EとWの実行タイミングは不連続である、EとWが離れることによって、Wの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。つまり、高い優先度が与えられたタスクは、特定の時刻で特定の処理が必ず行われる。
【0060】
図12:ステップ2246)
実行タイミング調停部124は、実行時間の総和が周期を超えないことを判定する。真である場合には本動作フローを終了し、偽である場合にはステップ2247に進む。
【0061】
図12:ステップ2247)
実行タイミング調停部124は、エラー情報をエラー通知部126経由でネットワークに送付し、縮退制御部125により縮退制御が実行され、本動作フローを終了する。
【0062】
本実施例2によれば、実施例1と同様な効果が得られる他、以下のような効果を得ることができる。
【0063】
本実施例2によると、優先度スケジューリングで実装された車両制御装置では、処理継続が必要なタスクグループによって、新たに実行タイミングで競合が発生しても、前記タスクグループのWのみを移動させ、スケジューラリビティが成立性する限り、リアルタイム性を保証できる。
【0064】
本実施例2によると、CPUが100%を超過しないことを確認するためのスケジューラビリティの検証を、実行時間の総和が周期を超えないことで判定したが、これに限らない。例えば、複数の周期からなる場合にはハイパーピリオドに基づいて検証する。
【0065】
本実施例2によると、RやEに関しては、同じタスクグループで優先度を同じとし、実行時間をR、Eの順にしているために、競合が発生しても、優先度スケジューリングに基づいて、調停が行われるため、実行タイミング調停部の処理を簡略化することができる。
【0066】
<実施例3>
本実施例3は処理継続が必要なタスクグループが移動先と同じ機能グループである場合の例である。スケジューリング方式は問わないため、実施例3は優先度スケジューリングで説明する。従って、実施例2との差分のみに絞って説明する。
【0067】
図13A図13B図13Cは実施例3に係るタスクセット情報331、332、333を示す。タスクセット情報はコアID、タスクグループ、タスクID、性質、周期、優先度、開始時間、実行時間、マージンから構成され、すべての項目は実施例2と同様である。
【0068】
図14は実施例3に係る処理継続判定表334を示す。処理継続判定表334は機能グループ、タスクグループ、タスクID、処理継続、ASIL、要求CPU使用率から構成され、すべての項目は実施例2と同様である。実施例2との差異は、タスクグループ2が属する機能グループが、タスクグループ1が属する機能グループ1と同様となっている点である。
【0069】
図15は実施例3に係るコア割当情報335を示す。コア割当情報335はコアID、ASIL、実行機能グループ、CPU使用率、マージン、CPU使用可能率から構成され、すべての項目は実施例2と同様である。実施例2との差異は、コアID2の実行機能グループが1、2となっている点である。
【0070】
図16A図16Bは実施例3に係るスケジューリングテーブル336、337を示す。スケジューリングテーブル336、337はタスクグループと開始時間から構成され、タスクグループと開始時間は実施例2と同じ意味を持つ。実施例2との差異は、実施例3に合わせてタスクグループIDが変更されている点である。
【0071】
図17は実施例3に係る実行タイミング調停部124の処理フローである。以下、図17の各ステップについて説明する。
【0072】
図17:ステップ3241)
実行タイミング調停部124は、処理継続が必要な前記タスクグループを、前記割当コアIDに追加するようにタスクセット情報を更新し、タスクセット情報332を作成する(図13B)。
【0073】
図17:ステップ3242)
実行タイミング調停部124は、前記コアIDにマージンを有する同じ機能グループが存在する場合には、優先度が低いE(特定のタスク)にマージンを集結させる(図13B)。
【0074】
図17:ステップ3243)
実行タイミング調停部124は、ハイパーピリオドに基づいてスケジューリングテーブル(図16A)を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。
【0075】
図17:ステップ3244)
実行タイミング調停部124は、同じ時刻に実行されるのタスクがある場合、それは処理継続が必要な前記タスクグループのWで発生したか否かを判定する。真である場合にはステップ3245に進み、偽である場合にはステップ3246に進む。
【0076】
図17:ステップ3445)
実行タイミング調停部124は、処理継続が必要な前記タスクグループのWを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、WはEよりも遅い時間に実行される。EとWの時間は離れていてもよい。Eは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のようにEとWが離れることによって、Wの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。
【0077】
図17:ステップ3246)
実行タイミング調停部124は、実行時間の総和が周期を超えないことを判定する。真である場合には本動作フローを終了し、偽である場合にはステップ3247に進む。
【0078】
図17:ステップ3247)
実行タイミング調停部124は、エラー情報をエラー通知部126経由でネットワークに送付し、縮退制御部125が縮退制御を実行し、本動作フローを終了する。
【0079】
実施例3によれば実施例2と同様な効果を得ることができる他、次のような効果を得ることができる。
【0080】
本実施例3によると、同じ機能グループに属するタスクグループが同じコアで実行されるとき、マージンを統合することができるため、実行時間が予測よりも長くなった場合に、全体のマージンが少なくても同様に吸収することができ、効率的に実装できる。
【0081】
<実施例4>
実施例4は、コア故障発生前に、予め各コア故障時のタスクセット情報を用意する場合の例である。実施例1との差分のみに絞って説明する。
【0082】
図18は、実施の形態4に係るECU1の機能ブロック図を示す。ECU1のコンフィグ生成部428は、コア故障発生前に予め各コア故障が発生した場合を想定し、各コアが故障した故障箇所を継続処理選定部122に出力する。そして、コア割当更新部123がコア割当を更新し、実行タミング調停部124が各タスクセット情報133を生成する。生成した各タスクセット情報133はスケジューラ427に格納される。故障検知時には、故障検知部421がスケジューラ427に故障箇所(コアID)を通知し、スケジューラ427はコアIDに基づいて、タスクセット情報133を選定する。
【0083】
本実施例4は、実施例1と同様な効果が得られる他、次のような効果を得ることができる。
本実施例4によると、故障発生の前に予め、各コア10が故障した場合に採用するタスクセット情報を用意することができるため、故障発生後に処理継続の必要があるタスクを特定のコア10で実行するまでの時間が早くなる。
【0084】
<実施例5>
実施例5は、コア10の故障発生時に、別のECUのコア10で処理継続の必要があるタスクを実行する場合の例である。実施例1との差分のみに絞って説明する。
【0085】
図19は、本発明の実施例5に係るシステムの構成図を示す。車両制御装置3は、ECU4と、ECU5と、ネットワーク6で構成される。ECU4とECU5は複数のCPU11とメモリ12で構成されており、ECU4、5の内部構成はCPU11の個数に差があるが、基本的には実施例1と同じである。
【0086】
図20は、実施例5に係るECU4、5の機能ブロック図を示す。ECU4は、実施例1で説明した故障検知部121と継続処理選定部122とを備える。継続処理選定部122の出力となるタスクグループ情報はネットワーク6を通じて、ECU5に送付され、コア割当更新部123の入力となる。ECU5は、コア割当更新部123と、実行タイミング調停部124と、縮退制御部125と、エラー通知部126と、スケジューラ127とを備える。
【0087】
図21A図21B図21Cは実施例5に係るタスクセット情報531、532、533を示す。タスクセット情報はECUID、コアID、タスクグループ、タスクID、性質、周期、優先度、開始時間、実行時間、マージンから構成される。実施例5は複数のECU4、5が対象となるために、ECUIDが追加されている点が他の実施例と異なる。
【0088】
図22は実施例5に係る処理継続判定表534を示す。処理継続判定表534は機能グループ、タスクグループ、タスクID、処理継続、ASIL、要求CPU使用率から構成され、すべての項目は実施例2と同様である。他の実施例との差異は、機能グループ3が追加されている点である。
【0089】
図23は実施例5に係るコア割当情報535を示す。コア割当情報535はECUID、コアID、ASIL、実行機能グループ、CPU使用率、マージン、CPU使用可能率から構成される。実施例5は複数のECU4、5が対象となるために、ECUIDが追加されている点が他の実施例と異なる。
【0090】
図24A図24Bは実施例5に係るスケジューリングテーブル536、537を示す。スケジューリングテーブル536、537はタスクグループと開始時間から構成され、タスクグループと開始時間は、他の実施例と同じ意味を持つ。他の実施例との差異は、実施例5に合わせてタスクグループIDが変更されている点である。
【0091】
本実施例5によれば、実施例1と同様な効果が得られる他、次のような効果が得られる。
【0092】
本実施例5によると、コア故障後に処理継続の必要があるタスクグループを同じECU内で実行できないとき、他のECUで実行することが可能となるため、可用性が向上できる。
【符号の説明】
【0093】
0、3・・・車両制御装置、1、4、5・・・ECU、2、6・・・ネットワーク、10・・・コア、11・・・CPU、12・・・メモリ、121・・・故障検知部、122・・・継続処理選定部、123・・・コア割当更新部、124・・・実行タイミング調停部、125・・・縮退制御部、126・・・エラー通知部、127・・・スケジューラ、136、137、236、237、336、337、536、537・・・スケジューリングテーブル
図1
図2
図3A
図3B
図3C
図4
図5
図6A
図6B
図7
図8
図9
図10A
図10B
図10C
図11A
図11B
図12
図13A
図13B
図13C
図14
図15
図16A
図16B
図17
図18
図19
図20
図21A
図21B
図21C
図22
図23
図24A
図24B