(57)【要約】【課題】本発明は、各コアの処理負荷を最適化する車両制御装置を提供する。【解決手段】本発明は、制御タスクの演算負荷に関する指標データをもとに、リアルタイムに前記演算負荷を推定する演算負荷推定部２２４１と、演算負荷をもとに、車両の動作を制御するタスクテーブルを更新するタスクテーブル更新部２２４５と、を備える。さらに、演算負荷推定部２２４１で推定した制御タスク毎の演算負荷を監視する演算負荷監視部２２４４を備える。【選択図】図４
2020029174.tif 000002
【特許請求の範囲】
【請求項１】
制御タスクの演算負荷に関する指標データをもとに、リアルタイムに前記演算負荷を推定する演算負荷推定部と、
前記演算負荷をもとに、車両の動作を制御するタスクテーブルを更新するタスクテーブル更新部と、
を備えることを特徴とする車両制御装置。
【請求項２】
請求項１において、
前記演算負荷推定部で推定した前記制御タスク毎の前記演算負荷を監視する演算負荷監視部を備えることを特徴とする車両制御装置。
【請求項３】
請求項１又は２において、
前記指標データは、演算経路毎の前記演算負荷の累積データに基づくことを特徴とする車両制御装置。
【請求項４】
請求項３において、
前記指標データは、変更可能なパラメータであることを特徴とする車両制御装置。
【請求項５】
請求項３において、
前記演算負荷推定部は、前記制御タスク毎、または前記制御タスクを複数まとめた制御タスク群、またはその両方に備えられたことを特徴とする車両制御装置。
【請求項６】
請求項５において、
前記演算負荷推定部は、実行した前記制御タスクの前記演算経路をもとに選択された前記累積データを、前記演算負荷に関する情報とすることを特徴とする車両制御装置。
【請求項７】
請求項２において、
前記演算負荷監視部と前記タスクテーブル更新部は、同じモジュールに属しており、前記演算負荷監視部の監視結果に基づいてリアルタイムに前記タスクテーブルを更新することを特徴とする車両制御装置。
【請求項８】
請求項７において、
前記演算負荷監視部と前記タスクテーブル更新部は、前記タスクテーブルに設けられており、前記タスクテーブルの実行中に前記制御タスクの実行順序を変更可能であることを特徴とする車両制御装置。
【請求項９】
請求項２において、
前記演算負荷監視部は、前記演算負荷推定部で推定した前記制御タスク毎の前記演算負荷を累積し、該累積の結果が閾値を越えた場合に前記制御タスクを変更する指令値を出力することを特徴とする車両制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両制御装置に関わるものである。
【背景技術】
【０００２】
本技術分野の背景技術として、特開２０１３−１９９１８０号公報（特許文献１）がある。
特許文献１では、タスク処理順序の組み合わせパターンをあらかじめタスクテーブルとして用意しておき、その組み合わせパターンを切り替えることによって、状況に応じてタスクを動的に割り当てている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−１９９１８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では，ソフトウェアを生成して各制御タスクの演算負荷を計測し、タスクテーブルを設計することが想定されるため、多くの時間を要することが課題である。今後、タスク数・コア数ともに増えた場合、その組み合わせは増加するため、開発工数の増加はより一層顕著となる。
【０００５】
本発明は、上記のような課題を解決するために、各コアの処理負荷を最適化する車両制御装置を提供する。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明に係る車両制御装置は、制御タスクの演算負荷に関する指標データをもとに、リアルタイムに前記演算負荷を推定する演算負荷推定部と、前記演算負荷をもとに、車両の動作を制御するタスクテーブルを更新するタスクテーブル更新部と、を備える。
【発明の効果】
【０００７】
本発明に係る車両制御装置によれば、各コアの処理負荷を最適化する車両制御装置を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】実施例共通の車両制御装置を搭載した車両１の構成図である。
【図２】実施例共通の車両制御システム２のハードウェア構成例である。
【図３】実施例共通のＥＣＵ２２の内部構成を示すブロック線図である。
【図４】実施例１のプロセッサが実行する制御プログラムのモジュール構成を示す図である。
【図５】実施例１におけるタスクテーブル構成の一例である。
【図６】実施例共通のタスクカテゴリの優先度の一例を示した図である。
【図７】実施例１の処理負荷監視機能が制御タスクテーブルを切り替える様子を示すフローチャートである。
【図８】実施例共通のある制御タスクをブロック線図で表した一例である。
【図９】図８のブロック線図における演算経路を示した図である。
【図１０】演算処理が発生する各演算ブロックのコスト表である。
【図１１】図９の演算経路毎の演算コストの合計値を示す表である。
【図１２】実施例１の演算負荷推定機能がリアルタイムに演算負荷を推定し、推定結果を推定データとして累積する様子を示したフローチャートである。
【図１３】本実施例共通のモデルを設計してから演算負荷推定を行うまでのプロセスである。
【図１４】実施例２のプロセッサが実行する制御プログラムのモジュール構成を示す図である。
【図１５】実施例２におけるタスクテーブル構成の一例である。
【図１６】実施例２のタスクテーブル更新部がタスクテーブルを更新する様子を示すフローチャートである。
【発明を実施するための形態】
【０００９】
近年、車両制御機能が年々増加しており、単位時間当たりにコアが処理する演算負荷が高まる傾向がある。処理負荷が増加すると、走行状況によっては規定時間内に要求される全ての制御タスクを実行できない恐れがあり、制御遅れや残タスクの打ち切りをせざるを得ないような問題がある。近年では、処理負荷能力が比較的低いコアを複数搭載したマルチコアマイコンの制御開発が主流となりつつあり、規定時間内に要求される制御タスクを一つのコアで全て実行できない問題はより一層顕著となる。
【００１０】
一般的には、プログラム実行開始からの経過時間(プロセッサ時間)を計測するような一般的な処理負荷計測用の関数を利用してリアルタイムに演算負荷を推定し、その結果に応じて制御タスクを変更するような方法がある。
【００１１】
しかし、このような一般的な計測負荷測定用の関数はマイコン環境に依存する可能性があり、車載組込み用に利用する場合は汎用性・再利用性に欠ける。
【００１２】
以上を踏まえて、以下、図面を用いて、本発明の車両制御装置の実施例について説明する。
【実施例１】
【００１３】
本発明の実施例１による車両の制御装置について説明する。なお、各図において、同一符号は同一部分を示す。まず、以下に示す実施例に共通の構成を図１、図２、図３を用いて説明する。
【００１４】
図１は、本実施例の車両制御装置を搭載した車両１の構成図である。車両１は車両制御装置によって電子的に制御される車両であり、車両制御システム２、通信装置３、車両制御システム４、駆動装置５、認識装置６、出力装置７、入力装置８、通知装置９を備える。
【００１５】
車両制御システム２は、車両１が備える各部を制御するシステムであり、例えば車載ネットワーク(CAN: Controller Area Network、CANFD: CAN with Flexible Data-rate、Ethernet(登録商標)など)とコントローラ(ECU: Electronic Control Unit)により構成される。車両制御システム４は、車両制御システム２とは異なる車載ネットワーク上に構成されたシステムである。
【００１６】
通信装置３は、車両制御システム２の外部と無線通信(例えば携帯電話の通信、無線LAN、WANなどを利用した通信)し、外界(インフラ、他車)の情報または、自車に関する情報を取得・送信する。通信装置３はさらに、診断端子(OBD)、Ethernet（登録商標）に関する端子、外部記録媒体(例えばUSBメモリ、SDカード等)端子などを有し、車両制御システム２と有線接続することにより通信する。
【００１７】
駆動装置５は、車両制御システム２による制御にしたがって、車両運動を制御する機械および電気装置(例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置など)を駆動するアクチュエータなどの装置である。
【００１８】
認識装置６は、(a)外界から入力される情報を取得して外界認識情報を生成する、カメラ、レーダ、LIDAR、超音波センサなどの外界センサ、(b)車両１の状態(運動状態、位置情報など)を認識する力学系センサ(加速度、車輪速度、GPS: Global Positioning system)などにより構成される。
【００１９】
出力装置７は、車両制御システム２と有線または無線で接続され、車両制御システム２から創出されるデータを受信し、メッセージ情報(例えば映像、音)などユーザが必要とする情報を表示または出力する液晶ディスプレイ、警告等、スピーカなどのデバイスである。入力装置８は、ユーザが車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための、例えばステアリング、ペダル、ボタン、レバー、タッチパネル、などのデバイスである。通知装置９は、車両１が外界に対して車両の状態などを通知するための、ランプ、LED、スピーカなどのデバイスである。
【００２０】
図２は、車両制御システム２のハードウェア構成例である。ネットワークリンク２１は、各制御装置を接続する通信ネットワークであり、例えばCANバスなどによって構成される。ECU２２は、ネットワークリンク２１、駆動装置５、認識装置６などに接続される。ECU２２は、駆動装置５や認識装置６を制御し、ネットワークリンク２１を介してデータを送受信する。ゲートウェイ(GW)２３は、ネットワークリンク２１間でデータを中継する。
【００２１】
図３は、ECU２２の内部構成を示すブロック図である。プロセッサ２２１は、キャッシュやレジスタなどの記憶素子を持ち、制御プログラムを実行することにより車両１の各機能部を制御する。プロセッサ２２１は、１以上のプロセッサコアを備える。I/O２２２は、ネットワークリンク２１、駆動装置５、認識装置６などとの間でデータを送受信する。タイマ２２３は、図示しないクロックを使用して、時刻を管理する。ROM(Read Only Memory)２２４は、制御プログラムなどの不揮発性データを保存する。RAM(Random Access Memory)２２５は、揮発性データを保存する。内部バス２２６は、ECU２２内部における通信のために用いられる。データフラッシュ２２７は、プロセッサ２２１が制御プログラムを実行するとき用いるデータを格納する記憶装置である。
【００２２】
図４は、本実施例におけるプロセッサ２２１が実行する制御プログラムのモジュール構成を示す図である。ＲＯＭ２２４に保存されている制御プログラムは、制御タスク群２２４１、タスクテーブル２２４２、制御タスク実行部２２４３を備える。
【００２３】
制御タスク群２２４１は、複数の制御タスクより構成される。ここでいう制御タスクは、制御プログラムが実施する制御演算をある程度まとまった単位に分割した処理である。例えば、1変数を演算する制御タスクや、複数の変数をもとにある機能を実現する制御タスクが考えられる。制御タスク群２２４１の構成要素である制御タスクには、演算負荷を推定する演算負荷推定機能２２４１１が設けられている。演算負荷推定機能２２４１１より算出された演算負荷推定結果は、RAM２２５に推定データ２２５１として格納される。尚，RAM２２５に格納される推定データ２２５１は、各制御タスクの演算負荷推定結果を累積する。また、タスクテーブル２２４２の全てのタスクを実行後、推定データ２２５１を初期化する、もしくは、次周期のタスクテーブル実行時に前回値を参照できるように、別のRAM２２５領域に前回値データとして値を格納してもよい。尚，演算負荷推定機能２２４１１の詳細については後述する。
【００２４】
タスクテーブル２２４２は、各プロセッサコアが実行すべきタスクの実行順序を定義したデータテーブルである。本実施例のタスクテーブル２２４２には、演算負荷監視機能２２４４やタスクテーブル更新部２２４５が一緒に設けられている。演算負荷監視機能２２４４は、前記演算負荷推定機能２２４１１より算出された、RAM225に格納されている推定データ２２５１を監視し、現在の演算負荷状況を判断する。また、タスクテーブル更新部２２４５は、前記演算負荷推定機能２２４１１から得られた演算負荷状況に関する情報をもとに、タスクテーブル２２４２を更新する機能を有する。
【００２５】
演算負荷監視機能２２４４は、推定データ２２５１がある閾値を超えている場合は、高負荷であると判断し、タスクテーブル更新部２２４５に通知する。タスクテーブル更新部２２４５は、受け取った通知をもとにタスクテーブル２２４２を更新する。このとき、タスクテーブル２２４２には、RAM２２５に格納された推定データ２２５１に応じて瞬時にタスクテーブルを切り替える機能を有しているため、リアルタイムにタスクテーブルを切り替えることが可能である。
【００２６】
制御タスク実行部２２４３は、各制御タスクを例えば周期的に繰り返し実行し、またはセンサ入力やユーザ操作などの非周期的なイベントを契機として実行する。各タスクには優先度が割り当てられており、同じプロセッサコアにおいて複数のタスクが同時に実行可能となった場合に、プロセッサコアは優先度が最も高いタスクを実行する。
【００２７】
図５は、本実施例におけるある周期におけるタスクテーブル２２４２の構成の一例である。制御タスクテーブルＡ、制御タスクテーブルＢ１、制御タスクテーブルＣ１を組み合わせたものが全制御タスクを実行する制御タスクテーブル２２４２とする。つまり、制御タスクテーブルＢ１、制御タスクテーブルＣ１は、全タスクテーブルを単に分割した通常タスクテーブルといえる。制御タスクテーブルＢ２は、制御タスクテーブルＢ１の中でも、高負荷時には実行しなくても良い制御タスクが省略された簡易タスクテーブルである。また、制御タスクＣ２は、制御タスクテーブルＣ１の中で実行しなくても良い制御タスクが省略された簡易タスクテーブルであり、Ｃ３は、更に省略された簡易タスクテーブルである。このとき、演算負荷監視機能２２４４は、RAM２２５に格納された推定データ２２５１に応じて、制御タスクテーブル切り替えの指令をタスクテーブル更新部２２４５に通知する。タスクテーブル更新部２２４５は、切り替え指令を受けた場合、制御タスクテーブルＢ１を実行すべきところ、制御タスクＢ２に切り替える。また、制御タスクＣ１を実行すべきところ、制御タスクＣ２または、制御タスクＣ３に切り替える。このようにすることで，車両高負荷時には、必要最低限の制御タスクを実行することができる。尚、制御タスクテーブルをＡ、Ｂ、Ｃの３種類に分けているが、これよりも少ない、もしくはそれ以上に分類しても良い。また、制御タスクテーブルＢを２種類、制御タスクテーブルＣを３種類としているが、それ以上の種類を用意しても良い。
【００２８】
図６は、タスクカテゴリの優先度の一例を示したものである。図６においては、快適性確保、ハードウェア保護、安全性確保、法規厳守の順に優先度が高くなる。制御タスクを省略したタスクテーブルを設計する際には、図６の優先度を参考に設計する。
【００２９】
図７は、本実施例における、演算負荷監視機能２２４４が制御タスクテーブルＡを実行後、制御タスクテーブルＢに切り替える様子を示すフローチャートである。本フローチャートは、制御タスク実行部２２４３がタスクテーブルを参照する際に開始される（Ｓ７００）。まず、現在実行されているタスクテーブルの制御タスクがどの程度まで実効されているかを確認し、タスクテーブルを変更可能なタイミングであるかを確認する（Ｓ７０１）。現在実行されているタスクテーブルが完了していない場合、次のタスクテーブルに切り替えることができないため、既存の制御タスクテーブル（Ｓ７０３）を継続して実行する（Ｓ７０２）。現在実行されているタスクテーブル内の制御タスクが全て実行完了となった場合には、次のタスクテーブルに変更するべく、まずRAM２２５に格納された推定データ２２５１を取得し、現在の負荷状況を確認する（Ｓ７０４）。取得した推定データ２２５１があらかじめ設計した閾値以下である場合には、通常のタスクテーブル（Ｓ７０６）を選択し、閾値以上である場合には、高負荷な運転状況でも実行できるようにある制御タスクを省略した簡易タスクテーブルを（Ｓ７０７）を選択する（Ｓ７０５）。尚、制御タスク実行部２２４３が各制御タスクを実行する度に、図７の処理は繰り返される。
【００３０】
続いて，本実施例の演算負荷推定について，図８、図９、図１０、図１１、図１２を用いて説明する。
【００３１】
図８は、ある制御タスクをブロック線図で表した一例である。図８のブロック線図は、制御タスクの入力を表すInportブロックＢ１、Ｂ２、入力に定数を乗算して増幅するGainブロックＢ３、乗算を行うProductブロックＢ４、定数値を生成して出力するConstantブロックＢ５、Ｂ６、比較演算を行うRelational OperatorブロックＢ７、一方の入力を他方の入力で除算するDivideブロックＢ８、１次元関数を近似し、入力を１次元関数に入力して演算結果を出力する1-D Lookup TableＢ９、２番目の入力の値に応じて、１番目の入力と３番目の入力を切り替えるSwitchブロックＢ１０、制御タスクの出力を表すOutportブロックＢ１１で構成される。
【００３２】
図８には、図９に示すように２つの演算経路が存在する。InportＢ１の入力を１０倍し、前記演算結果とInportＢ１とを掛け合わせた値をOutportＢ１１に出力する経路ａと、InportＢ２を２０で除算し、その結果を１次元関数に入力して得られた結果をOutportＢ１１に出力する経路ｂである。本実施例では、ブロック線図内で考えられる複数の経路毎に演算負荷を推定する。
【００３３】
図１０は、演算処理が発生する各演算ブロックのコスト表を表す。本実施例では、演算負荷に関わる指標データとして演算負荷コストを用い、演算負荷コストを各演算ブロックに事前に設計する。尚、Constantブロックなどの特定のブロックは、演算処理が発生しないため、演算負荷コストを割り当てていない。また、演算負荷コストは、ECU２２などのハードウェアや、ソフトウェアプラットフォームなどによって異なるため、変更毎に再設計する必要があるが、ハードウェアや開発環境が変更されない限り流用可能である。
【００３４】
本実施例では、各経路の演算ブロックに割り当てられた演算負荷コストを累積し、累積した演算負荷コストをもとに各経路の演算負荷を推定する。尚、経路の演算負荷を推定する際には、経路の演算負荷コストの累積値だけでなく、SwitchブロックＢ１０などの判定用に関わる演算負荷を考慮する(経路ｃ)。以上より、各経路の演算負荷コストは、下記のように求められる。
演算負荷コストの合計 = 経路の演算負荷コストの合計 + 判定用の演算負荷コストの合計
【００３５】
図１０のコスト表を用いて、経路ａ、経路ｂのコストを算出すると、下記のように求められる。尚、各経路の演算負荷コスト表として図１１にまとめている。
経路ａ = ( Ｃ１ + Ｃ２ + Ｃ６ ) + ( Ｃ３ )
経路ｂ = ( Ｃ４ + Ｃ５ + Ｃ６ ) + ( Ｃ３ )
【００３６】
図１２は、制御タスク毎に備えられた演算負荷推定機能２２４１１が、制御タスクが実行した経路からリアルタイムに演算負荷を推定し、推定結果を推定データ２２５１としてRAM２２５に格納、累積するまでの様子を示すフローチャートである。本フローチャートは、制御タスク実行部２２４３が、タスクテーブルの各制御タスクを実行する際に開始される（Ｓ１２０１）。タスク処理を実行後(Ｓ１２０２)、制御タスクを実行中に、どの演算経路を通過したかの判定を行う（Ｓ１２０３）。その後，通過経路に応じて図１１のような各経路の演算負荷コスト表をもとに演算負荷コストを導出する（Ｓ１２０４）。その後、導出した経路を推定データとしてRAMに格納し、演算負荷コストを累積していく。（Ｓ１２０５）。
【００３７】
図１３は、モデルを設計してから演算負荷推定を行うまでのプロセスを示している。図１３のように、コード生成やコンパイルを実施しなくても演算負荷を推定することが可能なため，演算負荷推定機能を実装するまでの期間を最小限に抑えられる。
【００３８】
図１１に示す各演算経路の演算負荷コストの合計値は、図１０に示す各演算ブロックの演算負荷コストが変更されることで変わる可能性がある。そのたえ、制御タスクコードを生成した後も値を変更できるように、各演算ブロックの演算負荷コストをマクロやキャリブレーションパラメータで実装することで，再利用性の高いソフトウェアを提供可能である。
【実施例２】
【００３９】
次に、実施例２による車両制御装置について説明する。尚、実施例１と同様の構成は説明を省略し、実施例１と異なる箇所を中心に説明する。
【００４０】
図１４は、実施例２における制御プログラムのモジュール構成を示す図である。実施例２における制御プログラムのモジュール構成の特徴は、演算負荷監視機能２２４４、制御タスクを更新するタスクテーブル更新部２２４５がそれぞれ別もモジュールとなり、タスクテーブル２２４２から独立している点や、RAM２２５に格納された制御タスク変更指令値２２５２をもとにタスクテーブル更新部がタスクテーブルを更新する点、である。演算負荷監視機能２２４４は、推定データ２２５１の値がある閾値以上となった場合、もしくはある閾値以下となった場合、制御タスク変更指令値２２５２を更新する。このとき、制御タスク実行部２２４３が１つの制御タスクを実行する毎に演算負荷監視機能２２４４を実行することも可能だが、本実施例では演算負荷削減の観点からタスクテーブル２２４２の先頭もしくは最後に演算負荷監視機能２２４４を実行する。尚、タスクテーブル２２４２の制御タスク間に複数回実行し、制御タスク変更指令値２２５２を更新する方法も考えられる。
【００４１】
図１５は、本実施例における、ある周期のタスクテーブル２２４２の構成例である。本実施例では、全ての制御タスクが記述される通常のタスクテーブルと、制御タスクの一部を省略した簡易タスクテーブルとする。本実施例では、タスクテーブルを２つのみとしているが、３つ以上となっても良い。
【００４２】
図１６は、タスクテーブル更新部が、タスクテーブル２２４２の先頭で制御タスク変更指令値２２５２を参照してからタスクテーブル２２４２を更新する様子を示すフローチャートである。制御タスク実行部がタスクテーブルを参照する際に開始される（Ｓ１６００）。まず、タスク実行状況を確認し（Ｓ１６０１）、タスクテーブルの先頭であるかを確認する（Ｓ１６０２）。タスクテーブルの先頭でない場合には、既存のタスクテーブルを継続し（Ｓ１６０３）、タスクテーブルの先頭である場合には、制御タスク変更指令値２２５２を取得する（Ｓ１６０４）。制御タスク変更指令値が閾値以下である場合、通常のタスクテーブルを実行する（Ｓ１６０６）。制御タスク変更指令値が閾値以上である場合には、図６などを参考にある制御タスクを省略した簡易タスクテーブルを実行する（Ｓ１６０７）。
【００４３】
以上の実施例１，２によれば、ブロック線図より得られた各経路の演算負荷に関わる指標データをもとに演算負荷を推定する演算負荷推定機能をソフトウェアに設けることで、演算負荷推定機能の推定結果をもとに制御タスクを変更してタスクテーブルを最適化することを可能とした。これにより、汎用性・再利用性を損なうことなく、設計者が意図しない制御遅れや残タスクの打ち切りを防止することが可能なソフトウェアを短期間で提供可能である。
【００４４】
また、演算負荷をリアルタイムに推定する機能を短時間でソフトウェア上に実装しつつ、各コアの処理能力以上の処理負荷が掛からないようにタスクテーブルを最適化する車両の制御装置を提供可能である。
【００４５】
実施例１，２を踏まえて、以下のように構成を表現することが可能である。
【００４６】
１．制御タスクの演算負荷に関する指標データをもとに、リアルタイムに前記演算負荷を推定する演算負荷推定部と、前記演算負荷をもとに、車両の動作を制御するタスクテーブルを更新するタスクテーブル更新部と、を備える。
【００４７】
２．上記１．において、前記演算負荷推定部で推定した前記制御タスク毎の前記演算負荷を監視する演算負荷監視部を備える。
【００４８】
３．上記１．又は２．において、前記指標データは、演算経路毎の前記演算負荷の累積データに基づく。
【００４９】
４．上記３．において、前記指標データは、変更可能なパラメータである。
【００５０】
５．上記３．において、前記演算負荷推定部は、前記制御タスク毎、または前記制御タスクを複数まとめた制御タスク群、またはその両方に備える。
【００５１】
６．上記５．において、前記演算負荷推定部は、実行した前記制御タスクの前記演算経路をもとに選択された前記累積データを、前記演算負荷に関する情報とする。
【００５２】
７．上記２．において、前記演算負荷監視部と前記タスクテーブル更新部は、同じモジュールに属しており、前記演算負荷監視部の監視結果に基づいてリアルタイムに前記タスクテーブルを更新する。
【００５３】
８．上記７．において、前記演算負荷監視部と前記タスクテーブル更新部は、前記タスクテーブルに設けられており、前記タスクテーブルの実行中に前記制御タスクの実行順序を変更可能である。
【００５４】
９．上記２．において、前記演算負荷監視部は、前記演算負荷推定部で推定した前記制御タスク毎の前記演算負荷を累積し、該累積の結果が閾値を越えた場合に前記制御タスクを変更する指令値を出力する。
【００５５】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上述した実施例をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の公正の一部を他の実施例の構成に置き換えることも可能であり、また、ある実施例の公正に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。フローチャートの構成は、一例であり、これに限定されるものではない。
【００５６】
また、ブロック線図については一例を説明したが、それ以外のブロック線図であっても適用可能である。
【符号の説明】
【００５７】
２２４１  演算負荷推定機能（演算負荷推定部）、２２４４  演算負荷監視機能（演算負荷監視部）、２２４５  タスクテーブル更新部
【図１】
2020029174.tif 000003
【図２】
2020029174.tif 000004
【図３】
2020029174.tif 000005
【図４】
2020029174.tif 000006
【図５】
2020029174.tif 000007
【図６】
2020029174.tif 000008
【図７】
2020029174.tif 000009
【図８】
2020029174.tif 000010
【図９】
2020029174.tif 000011
【図１０】
2020029174.tif 000012
【図１１】
2020029174.tif 000013
【図１２】
2020029174.tif 000014
【図１３】
2020029174.tif 000015
【図１４】
2020029174.tif 000016
【図１５】
2020029174.tif 000017
【図１６】
2020029174.tif 000018