JP2022098090A - 車両制御装置 - Google Patents

Abstract

【課題】故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供する。【解決手段】複数のタスクを時刻同期で実行するＣＰＵ11を有する車両制御装置であって、ＣＰＵ11のコア10の故障を検知する故障検知部121と、故障したコア10が実行していたタスクを故障していないコア10に割り当てる実行タイミング調停部124と、を備える。実行タイミング調停部124は、故障したコア10が実行していたタスクを故障していないコア10に割り当てるとき、故障していないコア10が実行するタスクを実行可能なように実行時刻を移動し、複数のタスクが実行可能な時刻を設定する。【選択図】図２

Description

本発明は、複数のＣＰＵを有する車両制御装置に関する。

自動車制御システムは複数の電子制御ユニット（ＥＣＵ）で構成される。ＥＣＵは厳しい時間制約（デッドライン）を満たすように、センサの入力処理、制御処理の目標値算出処理、アクチュエータの制御処理を実行する必要がある。低コスト化や省スペース化のためにＥＣＵの統合が進み、要求計算量の増加に対応したマルチコアが採用されている。

しかしながら、制御処理を実行しているコアに故障が発生した場合には、処理の継続実行が不可能となってしまうために、安全保証のためにＥＣＵ全体を停止する縮退制御が実行される。

従って、制御処理を継続実行可能な可用性を向上させる技術が求められる。
特許文献１記載の技術によると、ソフトウェアを実行するコアを定義した設定情報（コア割当情報）を予め動作モードに対応付けて保存し、コア故障検知時にはリセットをトリガに、正常動作可能なコアのみで実行できる動作モードに切り替えることで、ソフトウェアを実行するコアを変更し、可用性を向上できる。

特開２０１８－１１２９７７号公報

しかしながら、特許文献１に記載の技術では、コア移動後のソフトウェアがリアルタイム性を保証して実行可能であることが保証できていない。また、予め設計する必要があるために、ソフトウェア更新に対応することが難しい。
本発明は、上記のような課題を解決するためになされたものであり、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することを目的とする。

上記課題を解決するため、本発明は次のように構成される。
複数のタスクを時刻同期で実行するＣＰＵを有する車両制御装置であって、 前記ＣＰＵのコアの故障を検知する故障検知部と、故障した前記コアが実行していたタスクを故障していないコアに割り当てる実行タイミング調停部と、を備え、 前記実行タイミング調停部は、前記故障した前記コアが実行していた前記タスクを前記故障していないコアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を移動し、前記複数の前記タスクが実行可能な時刻を設定する。

本発明に係る車両制御装置によれば、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することができる。

実施例１、２、３及び４に係る車両制御装置の構成図である。 実施例１、２及び３に係る車両制御装置の機能ブロック図である。 実施例１に係るタスクセット情報を示す図である。 実施例１に係るタスクセット情報を示す図である。 実施例１に係るタスクセット情報を示す図である。 実施例１に係る処理継続判定表を示す図である。 実施例１に係るコア割当情報を示す図である。 実施例１に係るスケジューリングテーブルを示す図である。 実施例１に係るスケジューリングテーブルを示す図である。 実施例１に係る継続処理判定部の処理フローチャートである。 実施例１に係るコア割当更新部の処理フローチャートである。 実施例１に係る実行タイミング調停部の処理フローチャートである。 実施例２に係るタスクセット情報を示す図である。 実施例２に係るタスクセット情報を示す図である。 実施例２に係るタスクセット情報を示す図である。 実施例２に係るスケジューリングテーブルを示す図である。 実施例２に係るスケジューリングテーブルを示す図である。 実施例２に係る実行タイミング調停部の処理フローチャートである。 実施例３に係るタスクセット情報を示す図である。 実施例３に係るタスクセット情報を示す図である。 実施例３に係るタスクセット情報を示す図である。 実施例３に係る処理継続判定表を示す図である。 実施例３にコア割当情報を示す図である。 実施例３に係るスケジューリングテーブルを示す図である。 実施例３に係るスケジューリングテーブルを示す図である。 実施例３に係る実行タイミング調停部の処理フローチャートである。 実施例４に係る制御システムの機能ブロック図である。 実施例５に係るシステムの構成図である。 実施例５に係る制御システムの機能ブロック図である。 実施例５に係るタスクセット情報を示す図である。 実施例５に係るタスクセット情報を示す図である。 実施例５に係るタスクセット情報を示す図である。 実施例５に係る処理継続判定表を示す図である。 実施例５にコア割当情報を示す図である。 実施例５に係るスケジューリングテーブルを示す図である。 実施例５に係るスケジューリングテーブルを示す図である。

本発明に係る車両制御装置は、制御ソフトウェアを実行するコアの故障を検出し、故障したコアによって影響をうける処理において継続実行すべき処理を選択し、継続実行すべき処理を動作させるコアを決定する。

また、継続実行すべき処理の追加によって生じる実行タイミングの競合を判定し、調停する。調停後のタイミングで車両制御装置を動作させる。

以下、図面を用いて本発明の実施の形態について説明する。
＜実施例１＞
図１は、本発明の実施例１に係るシステムの構成図を示す図である。車両制御装置０は、ＥＣＵ１とネットワーク２で構成される。ＥＣＵ１は複数のＣＰＵ１１とメモリ１２で構成される。複数のＣＰＵ１１は、タスクを時刻同期で実行する。ＣＰＵ１１のそれぞれが複数のコア１０から構成される場合があるので、ＣＰＵ単体であってもマルチコアである可能性があり、本発明の対象となるが、本実施例１では１つのＣＰＵが１つのコア１０を有する。ＥＣＵ１には、ＣＰＵ１１が複数存在するので、ＥＣＵ１には、複数個のコア１０が配置されている。メモリ１２にはプログラムが保存される。メモリ１２の個数は問わない。

図２は、実施例１に係るＥＣＵ１の機能ブロック図を示す。ＥＣＵ１の故障検知部１２１はコア１０の故障を検知し、継続処理選定部１２２に故障箇所を通知する。継続処理選定部１２２は継続処理の対象となるタスクグループをコア割当更新部１２３に通知する。本実施例１では、ソフトウェア処理を実行する単位をタスクと呼ぶ。タスクはオペレーティングシステム（ＯＳ）が管理する実行管理対象であり、スレッドと同様である。

制御ソフトウェアの処理はタスクの中で実行されるため、１つのタスクのなかで複数の制御ソフトウェア処理を実行することもできる。コア割当更新部１２３は割当コアを選定し、前記タスクグループと共に実行タイミング調停部１２４に通知する。

実行タイミング調停部１２４は、新たに割り当てられた前記タスクグループと、本来割り当てられていたタスクグループの間の実行タイミング競合を検出する。つまり、故障したコア１０が実行していたタスクを故障していないコア１０が同時刻で実行できるか否かを検証する。そして、コア１０のタスクの実行タイミング（実行時刻）を変更する（移動する）ことで調停する。実行時刻の変更は、コア１０の入出力時間制約が供される範囲で行う。実行タイミング調停部１２４は、故障していたコア１０の複数のタスクが独立して実行可能な時刻を設定し、調停されたタスクセット情報とする。調停されたタスクセット情報はスケジューラ１２７に通知される。スケジューラ１２７はタスクセット情報に基づいて、時分割でタスクを実行する。スケジューラ１２７は、時刻同期で実行するタスクを制御し、特定の時刻で特定のタスクを実行する。調停ができなかった場合には、縮退制御部１２５を実行し、エラー通知部１２６が、エラーを他のＥＣＵにネットワーク経由で通知する。

図３Ａ、図３Ｂ、図３Ｃは実施例１に係るタスクセット情報１３１、１３２、１３３を示す図である。タスクセット情報はコアＩＤ、タスクグループ、タスクＩＤ、性質、周期、開始時間、終了時間、マージンから構成される。

コアＩＤとはＣＰＵ１１を識別するＩＤである。タスクグループとは制御ソフトウェアの集合を示し、値はタスクグループＩＤを示す。タスクＩＤとはタスクを識別するＩＤを示す。性質とはタスクの役割を示す。Ｒはタスクグループへの入力処理を実施する（Ｃｏｐｙ－Ｉｎ）入力処理タスクであることを示し、Ｅは制御処理を実行する制御処理タスクであることを示し、ＷはＥで算出した制御処理の結果を出力する（Ｃｏｐｙ－Ｏｕｔ）出力処理タスクであることを示す。

周期はタスクが実行される間隔を示す。開始時間はタスクが実行を開始する時間であり、単位はｍｓである。終了時間はタスクが終了する時間であり、単位はｍｓである。マージンはタスクの実行時間が変動する可能性を考慮して設けられた余裕時間（タスクの実行時間の余裕時間）であり、マージンの時間だけ終了時間が長く設定されている。単位はｍｓである。

図３Ａ)はコア故障発生前のタスクセット情報１３１であり、図３Ｂはコア割当先を決定したが調停前のタスクセット情報１３２であり、図３Ｃは調停後のタスクセット情報１３３を示す。

図４は実施例１に係る処理継続判定表１３４を示す。処理継続判定表１３４は機能グループ、タスクグループ、タスクＩＤ、処理継続、ＡＳＩＬ、要求ＣＰＵ使用率から構成される。機能グループとは、車両制御機能のまとまりを示し、値は機能グループＩＤを示す。例えば、エンジンを制御するソフトウェアのグループや、運転支援システムや自動運転のための目標操舵角度や加減速指令を計算するソフトウェアのグループである。

タスクグループは機能グループを実現する1つ以上のタスクの集合であり、値はタスクグループＩＤを示す。１つの機能グループは１つ以上のタスクからなるタスクグループで構成される。また、１つのタスクグループはＲ、Ｅ、Ｗで構成され、少なくとも出力処理タスクは時分割で実行される。ＥはＲの後で実行され、Ｗの前で実行される。タスクＩＤとはタスクを識別するＩＤを示す。処理継続とは、コア故障時にタスクグループの処理を継続するか否かを示す。「必要」とは処理を継続する必要があることを示し、「不必要」は処理を継続する必要がないことを示す。ＡＳＩＬとは機能安全規格ＩＳＯ２６２６２６で定義されたＡｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌの略で、求められる自動車安全水準を示す。ＱＭ、Ａ～Ｄでレベル付けされ、Ｄほど要求水準が高いことを意味する。要求ＣＰＵ使用率とは、タスクグループを実行するときに消費するＣＰＵ使用率を意味する。

図５は実施例１に係るコア割当情報１３５を示す。コア割当情報１３５はコアＩＤ、ＡＳＩＬ，実行機能グループ、ＣＰＵ使用率、マージン、ＣＰＵ使用可能率から構成される。コアＩＤとはＣＰＵ１１を識別するＩＤである。ＡＳＩＬとはコアが準拠するＡＳＩＬを示す。実行機能グループとは、コア１０が実行する機能グループを示し、値は機能グループＩＤを示す。

ＣＰＵ使用率とは前記実行機能グループを実行するときに消費するＣＰＵ負荷を意味する。マージンとはタスクグループの実行時間が予測から乖離したときにもリアルタイム性を保証するために要した時間的な余裕のことを意味する。ＣＰＵ使用可能率とは、前記ＣＰＵ使用率と前記マージンを除いた他のタスクグループを実行可能な程度を示す。

図６Ａ、図６Ｂは実施例１に係るスケジューリングテーブル１３６、１３７を示す。スケジューリングテーブルはタスクグループと開始時間から構成される。タスクグループとは、特定のコアで実行されるタスクグループＩＤを示す。開始時間とは特定の時間に実行されるタスクＩＤを示す。図６Ａは調停前のスケジューリングテーブル１３６を示し、図６Ｂは調停後のスケジューリングテーブル１３７を示す。

以降より、実施例１に係る動作フローの詳細を説明する。

図７は継続処理判定部１２２の処理フローである。以下、図７の各ステップについて説明する。

（図７：ステップ１２２１）
継続処理選定部１２２は故障箇所（コアＩＤ）に基づいてタスクセット情報から影響を受けるタスクグループを特定する。具体的にはタスクセット情報１３１からコアＩＤで実行されているタスクグループを特定する。

（図７：ステップ１２２２）
継続処理選定部１２２は特定した前記タスクグループから、処理継続判定表１３４に基づいて、前記タスクグループの停止によって影響を受ける機能グループを特定する。このステップ１２２２においては、処理継続判定表１３４に基づき、故障したコア１０に応じて影響を受ける機能グループが自動車安全水準に基づいて、特定される。

（図７：ステップ１２２３）
継続処理選定部１２２は、処理継続判定表１３４に基づいて、特定した機能グループのなかで、処理継続が必要となるタスクグループを特定する。

図８はコア割当更新部１２３の処理フローチャートである。以下、図８の各ステップについて説明する。

（図８：ステップ１２３１）
コア割当更新部１２３は、前記タスクグループの移動先を探すために、コア割当情報１３５を参照し、ＣＰＵ使用可能率が前記タスクグループの要求ＣＰＵ使用率も大きいコアＩＤを見つける。

（図８：ステップ１２３２）
コア割当更新部１２３は、ステップ１２３１で見つけた前記コアＩＤが故障を検知したＥＣＵと同じＥＣＵであるか否かを判定する。真である場合には本処理フローを終了し、偽である場合にはステップ１２３３に進む。

（図８：ステップ１２３３）
コア割当更新部１２３は、ステップ１２３１で見つけたコアＩＤを有するＥＣＵに、割当コアＩＤとＥＣＵに処理継続が必要なタスクグループ情報を送付する。

図９は実行タイミング調停部１２４の処理フローチャートである。以下、図９の各ステップについて説明する。

（図９：ステップ１２４０１）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループを、前記割当コアＩＤに追加するようにタスクセット情報を更新し、タスクセット情報１３２を作成する（図３Ｂ）。

（図９：ステップ１２４０２）
実行タイミング調停部１２４は、前記割当コアＩＤに複数の機能グループが存在する場合には、マージンを機能グループ数で割る（図３Ｂ）。

（図９：ステップ１２４０３）
実行タイミング調停部１２４は、ハイパーピリオドに基づいてスケジューリングテーブル（図６Ａ）を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。

（図９：ステップ１２４０４）
実行タイミング調停部１２４は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのＲで発生したか否かを判定する。真である場合にはステップ１２４０５に進み、偽である場合にはステップ１２４０６に進む。

（図９：ステップ１２４０５）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループのＲを開始時間が早く、かつ、空いている時間に移動する。

（図９：ステップ１２４０６）
実行タイミング調停部１２４は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのＥで発生したか否かを判定する。真である場合にはステップ１２４０７に進み、偽である場合にはステップ１２４０８に進む。

（図９：ステップ１２４０７）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループのＥを開始時間が早く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、ＥはＲよりも遅い時間に実行される。

（図９：ステップ１２４０８）
実行タイミング調停部１２４は、同じ時刻に実行されるタスクがある場合、それは処理継続が必要な前記タスクグループのＷで発生したか否かを判定する。真である場合にはステップ１２４０９に進み、偽である場合にはステップ１２４１０に進む。

（図９：ステップ１２４０９）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループのＷを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、ＷはＥよりも遅い時間に実行される。ＥとＷの時間は離れていてもよい。Ｅは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のようにＥとＷが離れることによって、Ｗの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。実行タイミング調停部１２４は、タスクグループの実行タイミングを、入力処理タスク、制御処理タスク及び出力処理タスクの実行順序を保ちつつ、変更（移動）して、実行タイミングを調停する。

（図９：ステップ１２４１０）
実行タイミング調停部１２４は、Ｗ、Ｅ、Ｒのタスクが空いている開始時間に移動できたか否かを判断する。真である場合には本動作フローを終了し、偽である場合にはステップ１２４１１に進む。

（図９：ステップ１２４１１）
実行タイミング調停部１２４は、エラー情報をエラー通知部１２６経由でネットワーク２に送付し、縮退制御部１２５に縮退制御の実行を通知し、本動作フローを終了する。

以上のように、実行タイミング調停部１２４は、同一周期にて、出力タスクの実行までに入力処理タスクＲと制御処理タスクＥを、移動可能か否かを判定し、移動でいない場合は、エラーを通知し縮退制御が行われる。なお、ステップ１２４１１においては、エラー通知または縮退制御の通知を行うこととしてもよい。本実施例１によると、コア故障が発生しても処理継続が必要なタスクが別のコアで実行が可能となるために可用性が向上する。

また、本実施例１によると、処理継続が必要なタスクが別のコアで実行する場合に、処理の実行タイミング競合が発生しても、実行順序を守りつつ、空き時間に実行タイミングを変更するために、制御演算結果に影響を出さず、かつ、デッドラインを保証できる。

また、本実施例１によると、処理の実行タイミングに競合が発生した場合に、処理継続が必要なタスクの実行時間を変更し、元々実行していたタスクに影響を与えないために、リアルタイム性の影響を与える範囲を局所化できる。

また、本実施例１によると、ＥのタスクとＷのタスクが分離され、時間が空いているために、Ｅのタスクが予測時間より長く実行されたとしてもマージンで吸収され、Ｗのタスクの実行時間には影響を与えない。従って、検証範囲を局所化することができる。

本実施例１によれば、故障したコアに応じてソフトウェアの移動先を決定し、コア移動後のソフトウェア動作に基づいて実行タイミングの競合を判定し、競合する場合には調停することで、安全性と可用性を向上することが可能な車両制御装置を提供することができる。 なお、本実施例１によると、タスクは実行可能なタイミングを時刻で管理された時分割スケジューリングに基づいて実装されているが、これに限らない。

＜実施例２＞
実施例２は本発明を優先度スケジューリングで実現する例である。実施例１との差分のみに絞って説明する。

図１０は実施例２に係るタスクセット情報２３１、２３２、２３３を示す。タスクセット情報はコアＩＤ、タスクグループ、タスクＩＤ、性質、周期、優先度、開始時間、実行時間、マージンから構成される。コアＩＤ、タスクグループ、タスクＩＤ、性質、周期、開始時間、マージンは実施例１と同様である。優先度とは、複数のタスクが実行可能状態である場合に、先に実行する順番を決定するための数字で、数字が小さいほど優先度が高い。実行時間とは、タスクが実行に要する時間である。実行時間は設計時に規定した予測に基づいた値で規定されるが、出荷後に想定よりも大きくなる可能性を見越してマージンが設けられている。実行時間にはマージンの時間を含んでいない。同じタスクグループのＲとＥは同じ優先度としているがこれに限らない。Ｒの後にＥが実行されるようになっていれば変更可能である。一方、ＷはＲやＥよりも優先度を高く設定する。これは出力タイミングを固定にすることで、他からの影響を受けないようにし、検証する範囲を局所化するためである。

図１１Ａ、図１１Ｂは実施例２に係るスケジューリングテーブル２３６、２３７を示す。スケジューリングテーブルはタスクグループと開始時間から構成され、タスクグループと開始時間は実施例１と同じ意味を持つ。

図１２は実施例２に係る実行タイミング調停部２２４の処理フローである。以下、図１２の各ステップについて説明する。

（図１２：ステップ２２４１）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループを、前記割当コアＩＤに追加するようにタスクセット情報を更新し、タスクセット情報２３２を作成する（図１０Ｂ）。

（図１２：ステップ２２４２）
実行タイミング調停部１２４は、同一の前記コアＩＤに複数の機能グループが存在する場合には、マージンを機能グループ数で割る（図１０Ｂ）。

（図１２：ステップ２２４３）
実行タイミング調停部１２４は、ハイパーピリオドに基づいてスケジューリングテーブル（図１１Ａ）を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。

（図１２：ステップ２２４４）
実行タイミング調停部１２４は、同じ時刻に実行されるのタスクがある場合、それは処理継続が必要な前記タスクグループのＷで発生したか否かを判定する。真である場合にはステップ２２４５に進み、偽である場合にはステップ２２４６に進む。

（図１２：ステップ２４４５）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループのＷを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、ＷはＥよりも遅い時間に実行される。ＥとＷの時間は離れていてもよい。Ｅは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のように、ＥとＷの実行タイミングは不連続である、ＥとＷが離れることによって、Ｗの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。つまり、高い優先度が与えられたタスクは、特定の時刻で特定の処理が必ず行われる。

（図１２：ステップ２２４６）
実行タイミング調停部１２４は、実行時間の総和が周期を超えないことを判定する。真である場合には本動作フローを終了し、偽である場合にはステップ２２４７に進む。

（図１２：ステップ２２４７）
実行タイミング調停部１２４は、エラー情報をエラー通知部１２６経由でネットワークに送付し、縮退制御部１２５により縮退制御が実行され、本動作フローを終了する。

本実施例２によれば、実施例１と同様な効果が得られる他、以下のような効果を得ることができる。

本実施例２によると、優先度スケジューリングで実装された車両制御装置では、処理継続が必要なタスクグループによって、新たに実行タイミングで競合が発生しても、前記タスクグループのＷのみを移動させ、スケジューラリビティが成立性する限り、リアルタイム性を保証できる。

本実施例２によると、ＣＰＵが１００％を超過しないことを確認するためのスケジューラビリティの検証を、実行時間の総和が周期を超えないことで判定したが、これに限らない。例えば、複数の周期からなる場合にはハイパーピリオドに基づいて検証する。

本実施例２によると、ＲやＥに関しては、同じタスクグループで優先度を同じとし、実行時間をＲ、Ｅの順にしているために、競合が発生しても、優先度スケジューリングに基づいて、調停が行われるため、実行タイミング調停部の処理を簡略化することができる。

＜実施例３＞
本実施例３は処理継続が必要なタスクグループが移動先と同じ機能グループである場合の例である。スケジューリング方式は問わないため、実施例３は優先度スケジューリングで説明する。従って、実施例２との差分のみに絞って説明する。

図１３Ａ、図１３Ｂ、図１３Ｃは実施例３に係るタスクセット情報３３１、３３２、３３３を示す。タスクセット情報はコアＩＤ、タスクグループ、タスクＩＤ、性質、周期、優先度、開始時間、実行時間、マージンから構成され、すべての項目は実施例２と同様である。

図１４は実施例３に係る処理継続判定表３３４を示す。処理継続判定表３３４は機能グループ、タスクグループ、タスクＩＤ、処理継続、ＡＳＩＬ、要求ＣＰＵ使用率から構成され、すべての項目は実施例２と同様である。実施例２との差異は、タスクグループ２が属する機能グループが、タスクグループ１が属する機能グループ１と同様となっている点である。

図１５は実施例３に係るコア割当情報３３５を示す。コア割当情報３３５はコアＩＤ、ＡＳＩＬ、実行機能グループ、ＣＰＵ使用率、マージン、ＣＰＵ使用可能率から構成され、すべての項目は実施例２と同様である。実施例２との差異は、コアＩＤ２の実行機能グループが１、２となっている点である。

図１６Ａ、図１６Ｂは実施例３に係るスケジューリングテーブル３３６、３３７を示す。スケジューリングテーブル３３６、３３７はタスクグループと開始時間から構成され、タスクグループと開始時間は実施例２と同じ意味を持つ。実施例２との差異は、実施例３に合わせてタスクグループＩＤが変更されている点である。

図１７は実施例３に係る実行タイミング調停部１２４の処理フローである。以下、図１７の各ステップについて説明する。

（図１７：ステップ３２４１）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループを、前記割当コアＩＤに追加するようにタスクセット情報を更新し、タスクセット情報３３２を作成する（図１３Ｂ）。

（図１７：ステップ３２４２）
実行タイミング調停部１２４は、前記コアＩＤにマージンを有する同じ機能グループが存在する場合には、優先度が低いＥ（特定のタスク）にマージンを集結させる（図１３Ｂ）。

（図１７：ステップ３２４３）
実行タイミング調停部１２４は、ハイパーピリオドに基づいてスケジューリングテーブル（図１６Ａ）を作成し、処理継続が必要な前記タスクグループと同じ開始時刻に実行される別のタスクグループがあるか否かを調査する。

（図１７：ステップ３２４４）
実行タイミング調停部１２４は、同じ時刻に実行されるのタスクがある場合、それは処理継続が必要な前記タスクグループのＷで発生したか否かを判定する。真である場合にはステップ３２４５に進み、偽である場合にはステップ３２４６に進む。

（図１７：ステップ３４４５）
実行タイミング調停部１２４は、処理継続が必要な前記タスクグループのＷを開始時間が遅く、かつ、空いている時間に移動する。タスクグループ内で実行順序を保つために、ＷはＥよりも遅い時間に実行される。ＥとＷの時間は離れていてもよい。Ｅは予測した時間よりも超過する可能性があるが、マージンによって吸収される。現在のようにＥとＷが離れることによって、Ｗの実行タイミングが固定となるために、他のタスクグループを変更する必要がなく、リアルタイム性が保証できる。

（図１７：ステップ３２４６）
実行タイミング調停部１２４は、実行時間の総和が周期を超えないことを判定する。真である場合には本動作フローを終了し、偽である場合にはステップ３２４７に進む。

（図１７：ステップ３２４７）
実行タイミング調停部１２４は、エラー情報をエラー通知部１２６経由でネットワークに送付し、縮退制御部１２５が縮退制御を実行し、本動作フローを終了する。

実施例３によれば実施例２と同様な効果を得ることができる他、次のような効果を得ることができる。

本実施例３によると、同じ機能グループに属するタスクグループが同じコアで実行されるとき、マージンを統合することができるため、実行時間が予測よりも長くなった場合に、全体のマージンが少なくても同様に吸収することができ、効率的に実装できる。

＜実施例４＞
実施例４は、コア故障発生前に、予め各コア故障時のタスクセット情報を用意する場合の例である。実施例１との差分のみに絞って説明する。

図１８は、実施の形態４に係るＥＣＵ１の機能ブロック図を示す。ＥＣＵ１のコンフィグ生成部４２８は、コア故障発生前に予め各コア故障が発生した場合を想定し、各コアが故障した故障箇所を継続処理選定部１２２に出力する。そして、コア割当更新部１２３がコア割当を更新し、実行タミング調停部１２４が各タスクセット情報１３３を生成する。生成した各タスクセット情報１３３はスケジューラ４２７に格納される。故障検知時には、故障検知部４２１がスケジューラ４２７に故障箇所（コアＩＤ）を通知し、スケジューラ４２７はコアＩＤに基づいて、タスクセット情報１３３を選定する。

本実施例４は、実施例１と同様な効果が得られる他、次のような効果を得ることができる。
本実施例４によると、故障発生の前に予め、各コア１０が故障した場合に採用するタスクセット情報を用意することができるため、故障発生後に処理継続の必要があるタスクを特定のコア１０で実行するまでの時間が早くなる。

＜実施例５＞
実施例５は、コア１０の故障発生時に、別のＥＣＵのコア１０で処理継続の必要があるタスクを実行する場合の例である。実施例１との差分のみに絞って説明する。

図１９は、本発明の実施例５に係るシステムの構成図を示す。車両制御装置３は、ＥＣＵ４と、ＥＣＵ５と、ネットワーク６で構成される。ＥＣＵ４とＥＣＵ５は複数のＣＰＵ１１とメモリ１２で構成されており、ＥＣＵ４、５の内部構成はＣＰＵ１１の個数に差があるが、基本的には実施例１と同じである。

図２０は、実施例５に係るＥＣＵ４、５の機能ブロック図を示す。ＥＣＵ４は、実施例１で説明した故障検知部１２１と継続処理選定部１２２とを備える。継続処理選定部１２２の出力となるタスクグループ情報はネットワーク６を通じて、ＥＣＵ５に送付され、コア割当更新部１２３の入力となる。ＥＣＵ５は、コア割当更新部１２３と、実行タイミング調停部１２４と、縮退制御部１２５と、エラー通知部１２６と、スケジューラ１２７とを備える。

図２１Ａ、図２１Ｂ、図２１Ｃは実施例５に係るタスクセット情報５３１、５３２、５３３を示す。タスクセット情報はＥＣＵＩＤ、コアＩＤ、タスクグループ、タスクＩＤ、性質、周期、優先度、開始時間、実行時間、マージンから構成される。実施例５は複数のＥＣＵ４、５が対象となるために、ＥＣＵＩＤが追加されている点が他の実施例と異なる。

図２２は実施例５に係る処理継続判定表５３４を示す。処理継続判定表５３４は機能グループ、タスクグループ、タスクＩＤ、処理継続、ＡＳＩＬ、要求ＣＰＵ使用率から構成され、すべての項目は実施例２と同様である。他の実施例との差異は、機能グループ３が追加されている点である。

図２３は実施例５に係るコア割当情報５３５を示す。コア割当情報５３５はＥＣＵＩＤ、コアＩＤ、ＡＳＩＬ、実行機能グループ、ＣＰＵ使用率、マージン、ＣＰＵ使用可能率から構成される。実施例５は複数のＥＣＵ４、５が対象となるために、ＥＣＵＩＤが追加されている点が他の実施例と異なる。

図２４Ａ、図２４Ｂは実施例５に係るスケジューリングテーブル５３６、５３７を示す。スケジューリングテーブル５３６、５３７はタスクグループと開始時間から構成され、タスクグループと開始時間は、他の実施例と同じ意味を持つ。他の実施例との差異は、実施例５に合わせてタスクグループＩＤが変更されている点である。

本実施例５によれば、実施例１と同様な効果が得られる他、次のような効果が得られる。

本実施例５によると、コア故障後に処理継続の必要があるタスクグループを同じＥＣＵ内で実行できないとき、他のＥＣＵで実行することが可能となるため、可用性が向上できる。

０、３・・・車両制御装置、１、４、５・・・ＥＣＵ、２、６・・・ネットワーク、１０・・・コア、１１・・・ＣＰＵ、１２・・・メモリ、１２１・・・故障検知部、１２２・・・継続処理選定部、１２３・・・コア割当更新部、１２４・・・実行タイミング調停部、１２５・・・縮退制御部、１２６・・・エラー通知部、１２７・・・スケジューラ、１３６、１３７、２３６、２３７、３３６、３３７、５３６、５３７・・・スケジューリングテーブル

Claims (12)

1. 複数のタスクを時刻同期で実行するＣＰＵを有する車両制御装置であって、
   前記ＣＰＵのコアの故障を検知する故障検知部と、
   故障した前記コアが実行していたタスクを故障していないコアに割り当てる実行タイミング調停部と、
   を備え、
   前記実行タイミング調停部は、前記故障した前記コアが実行していた前記タスクを前記故障していない前記コアに割り当てるとき、前記故障していない前記コアが実行する前記タスクを実行可能なように実行時刻を移動し、前記複数の前記タスクが実行可能な時刻を設定することを特徴とする車両制御装置。
2. 請求項１に記載の車両制御装置において、
   前記故障した前記コアの前記タスクの実行を継続するか否かを自動車安全水準に基づいて判定することを特徴とする車両制御装置。
3. 請求項１に記載の車両制御装置において、
   前記実行タイミング調停部は、前記故障した前記コアの前記タスクが属する車両の機能グループが前記故障していない前記コアの前記タスクが属する前記車両の機能グループに属する場合、前記タスクの実行時間の余裕時間であるマージンを特定の前記タスクに集結させることを特徴とすることを車両制御装置。
4. 請求項１に記載の車両制御装置において、
   車両の機能グループが１つ以上の前記タスクからなるタスクグループで構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクで構成され、前記制御処理タスクは前記入力処理タスクの後で実行され、前記出力処理タスクの前で実行され、少なくとも前記出力処理タスクは時分割実行されることを特徴とする車両制御装置。
5. 請求項１に記載の車両制御装置において、
   時刻同期で実行される前記タスクを制御し、特定の時刻で特定の処理を実行するスケジューラを備えることを特徴とする車両制御装置。
6. 請求項４に記載の車両制御装置において、
   前記タスクには優先度が与えられ、高い優先度が与えられた前記タスクは、特定の時刻で特定の処理を実行する優先度スケジューラを備えることを特徴とする車両制御装置。
7. 請求項４に記載の車両制御装置において、
   前記実行タイミング調停部は、前記タスクグループの実行時刻を、前記入力処理タスク、前記制御処理タスク及び前記出力処理タスクの実行順序を保ちつつ、移動することを特徴とする車両制御装置。
8. 請求項４に記載の車両制御装置において、
   前記実行タイミング調停部は、同一周期にて、前記出力処理タスクの実行までに、前記入力処理タスク及び前記制御処理タスクが終了する時間を、移動可能か否かを判定し、移動できない場合には、縮退制御の通知またはエラー通知を行うことを特徴とする車両制御装置。
9. 請求項１に記載の車両制御装置において、
   車両の機能グループが、１つ以上の前記タスクからなるタスクグループにより構成され、複数の前記機能グループの前記タスクグループが同一の前記コアに存在する場合には、前記タスクの実行時間の余裕時間であるマージンを前記機能グループの数で割ることを特徴とする車両制御装置。
10. 請求項１に記載の車両制御装置において、
    車両の機能グループが、１つ以上の前記タスクからなるタスクグループにより構成され、前記タスクグループは、入力処理タスク、制御処理タスク及び出力処理タスクにより構成され、前記制御処理タスクと前記出力処理タスクの実行タイミングは不連続であることを特徴とする車両制御装置。
11. 請求項１に記載の車両制御装置において、
    車両の機能グループが、１つ以上の前記タスクからなるタスクグループにより構成され、前記故障した前記コアが実行していた前記タスクグループのうち、継続処理が必要な前記タスクグループを特定する継続処理選定部を備えることを特徴とする車両制御装置。
12. 請求項１に記載の車両制御装置において、
    前記コアは複数個であり、前記複数個の前記コアは、故障発生前に前記複数個の前記コアのそれぞれが故障した場合を想定し、前記複数個の前記コアの故障個所を出力するコンフィグ生成部と、前記コンフィグ生成部が生成した前記複数個の前記コアの故障個所に基づいたタスクセット情報を格納するスケジューラと、 を備え、
    前記スケジューラは、前記故障検知部が、前記コアの故障を検知すると、前記スケジューラに格納された前記タスクセット情報から前記故障した前記コアに対応する前記タスクセット情報を選定することを特徴とする車両制御装置。

Images