JP2012103802A - 情報処理装置、電子制御ユニット - Google Patents

Abstract

【課題】デッドライン時間までの間に終了処理や通常タスクを阻害せずにプライマリチェックを適切に実行することができる情報処理装置を提供する。
【解決手段】起動指示から起動開始までの期限が定められたタスクを実行する情報処理装置であって、タスクの開始までに実行すべき複数の初期処理タスク及び該初期処理タスク毎の予想実行時間が登録された初期処理タスクテーブルと、起動指示を受け付けた起動指示時刻を記録する起動指示時刻記録手段と、期限から起動指示時刻からの経過時間を減じた残時間と、予想実行時間を比較して、期限までに実行する初期処理タスクを決定するタスクスケジュール手段と、初期処理タスクを実行する初期処理タスク実行手段と、を有する。
【選択図】図２

Description

本発明は、車両に搭載される情報処理装置に関し、初期処理の後にタスクを実行する情報処理装置に関する。

車載されているＥＣＵ（Electronic Control Unit）は、動作を保証するため起動時と終了時に特定の処理を行うようになっている。ＥＣＵは、例えば、ＩＧ（イグニッション）＝ＯNにより初期処理（ソフトリセット＆プライマリチェック）を開始し、その後、通常処理を開始してＩＧ＝ＯＦＦになるまでは通常処理を実行し、ＩＧ＝ＯＦＦにより終了処理を開始し、それが終わるとリレーをオフにする。したがって、初期処理に相当するプライマリチェックが終了しないと、通常処理が開始されないため、次のような不都合が生じうる。

図１は、プライマリチェックと通常処理のタイミングチャート図の一例を示す図である。上段は不都合が生じない場合を、下段は不都合が生じる場合をそれぞれ示す。
ＩＧ＝ＯＮからＩＧ＝ＯＦＦになると通常処理が終了し、ＥＣＵは終了処理を開始する。終了処理の途中に、ＩＧ＝ＯＮになると、ＥＣＵは終了処理を停止せず継続する。
終了処理が終了すると、ＥＣＵはプライマリチェックを開始し、プライマリチェックが終了すると通常処理を開始する。

このため、下段のように、終了処理が終了するまでに長い時間がかかると、プライマリチェックが開始される時間が遅くなる。終了処理の内容は、ＩＧ＝ＯＮからＩＧ＝ＯＦＦになった時のＥＣＵの処理対象の状態（アクチュエータやＥＣＵのハード）により変わるため、終了処理が終了するまでの時間は不定である。

プライマリチェックが終了までの時間はほぼ同じであるが、終了処理が長くかかると、プライマリチェックが終了する時刻もずれ込み通常処理の開始時刻が遅くなる。しかしながら、例えば、機能統合によりＣＡＮゲートウェイの機能がＥＣＵに統合された場合、他のＥＣＵがＣＡＮ通信するには、機能統合されたＥＣＵのプライマリチェックが終了することが必要になる。図では、通常処理がＣＡＮゲートウェイの機能を制御するアプリである。

下段のように、他のＥＣＵがＣＡＮ通信を開始するまでに通常処理が起動しないと、他のＥＣＵは通信できないため、プライマリチェック中のＥＣＵに異常があると誤検出し、その後の制御もＥＣＵが存在しないことを前提とするため連携が困難になるおそれがある。

他のＥＣＵがプライマリチェックしているＥＣＵと通信を開始するまでの時間（例えば、ＩＧ＝ＯＮからの）はおよそ固定であるので、この時間（デッドライン時間）までに機能統合したＥＣＵはプライマリチェックを終了させることが好ましい。このように、ＥＣＵにはＩＧ＝ＯＮになってから通常処理を開始すべき時間にデッドライン時間が存在する。

したがって、上記の不都合を回避するためには、ＩＧ＝ＯＮからデッドライン時間までの間にＥＣＵにプライマリチェックを終了させればよいことになる。このような技術として、２つの処理が競合した際に、処理の優先度を考慮する技術がある（例えば、特許文献１参照。）。特許文献１には、優先度が高いジョブの処理を優先して、許容待ち時間が経過したら優先度の低いジョブを打ち切るジョブの処理方法が開示されている。

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

しかしながら、特許文献１のように優先度を考慮して、ＥＣＵが優先度の高い通常処理に優先的に処理を切り替えると、プライマリチェックのうち優先度の低い処理が常に実行されないおそれがあるという問題がある。換言すると、プライマリチェックのうちほとんど実行されない処理が生じうる。よって、単に優先度を考慮してプライマリチェックと通常処理を切り替えるだけでは、ＥＣＵがデッドライン時間を考慮して通常処理を優先しながら、適切にプライマリチェックを実行することは困難である。

ところで、デッドラインがあるなら、デッドラインの到来までに実行可能な処理だけを実行することも考えられる（例えば、特許文献２参照。）。特許文献２には、プロセッサによるタスクの実行状況を判断し、新たなタスクに許容可能な実行可能時間を実行制御手段に通知することで、実行可能時間が予め定められているタスクの実行時間を越える場合には、タスク群内のタスクを選択してプロセッサに与える情報処理装置が開示されている。

しかし、特許文献２の情報処理装置は、プロセッサの処理負荷から実行可能時間を決定するため、デッドライン時間を考慮してプライマリチェックの各処理をスケジュールすることは考慮されていない。

本発明は、上記課題に鑑み、デッドライン時間までの間に終了処理や通常処理を阻害せずにプライマリチェックを適切に実行することができる情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、起動指示から起動開始までの期限が定められたタスクを実行する情報処理装置であって、前記タスクの開始までに実行すべき複数の初期処理タスク及び該初期処理タスク毎の予想実行時間が登録された初期処理タスクテーブルと、前記起動指示を受け付けた起動指示時刻を記録する起動指示時刻記録手段と、前記期限から前記起動指示時刻からの経過時間を減じた残時間と、前記予想実行時間を比較して、前記期限までに実行する前記初期処理タスクを決定するタスクスケジュール手段と、前記初期処理タスクを実行する初期処理タスク実行手段と、を有することを特徴とする。

デッドライン時間までの間に終了処理や通常処理を阻害せずにプライマリチェックを適切に実行することができる情報処理装置を提供することができる。

プライマリチェックと通常タスクのタイミングチャート図の一例を示す図である。 情報処理装置による特徴的な処理の概略を説明する図の一例である。 プライマリチェックの実行方法が適用されたＥＣＵを含む電源供給システムの概略構成図の一例である。 ＨＶ−ＥＣＵの機能ブロック図の一例である。 各初期タスクの実行予想時間を示す図の一例である。 ＨＶ−ＥＣＵが実行する初期タスクを決定する手順を示すフローチャート図の一例である。 初期タスク実行処理、通常タスク実行処理、及び、終了処理の手順を示すフローチャート図の一例である。 タスク制御部が、実行可能なＰ／Ｃを決定し初期タスクテーブルに登録する手順を示すフローチャート図の一例である。 ＨＶ−ＥＣＵのタイミングチャート図の一例である（実施例２）。 実行回数テーブルの一例である。 初期タスク実行部が実行するＰ／Ｃを決定する手順を示すフローチャート図の一例である（実施例２）。 実行回数テーブルの一例である。 ＨＶ−ＥＣＵのタイミングチャート図の一例である（実施例３）。 各通常タスクのデッドラインと、通常タスクと関連の強い初期タスクを示す図の一例である。 ＨＶ−ＥＣＵが実行する初期タスクを決定する手順を示すフローチャート図の一例である（実施例３）。 ＨＶ−ＥＣＵのタイミングチャート図の一例である（実施例４）。 ＨＶ−ＥＣＵが実行する初期タスクを決定する手順を示すフローチャート図の一例である（実施例４）。 ＨＶ−ＥＣＵのタイミングチャート図の一例である（実施例５）。 ＨＶ−ＥＣＵがＰ／Ｃと通常タスクを実行する手順を示すフローチャート図の一例である（実施例５）。 リスクランクテーブルの一例である。 タスク制御部が初期タスクを実行する手順を示すフローチャート図の一例である（実施例６）。 通常タスクと並行に実行可能な初期タスクが登録された実行可能初期タスクテーブルの一例を示す（実施例７）。 タスク制御部がＰ／Ｃを実行する手順を示すフローチャート図の一例である（実施例７）。

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

図２は、本実施形態の情報処理装置による特徴的な処理の概略を説明する図の一例である。図２の上段は比較のために示した従来例である。

まず、イグニッション（ＩＧ）＝ＯＦＦからＯＮになるとリセットの後、初期処理（以下、プライマリチェック（Ｐ／Ｃ）という）が開始される（不図示）。そして、通常タスクが開始されるが、ＩＧ＝ＯＮからＩＧ＝ＯＦＦになると、通常タスクが終了し、ＥＣＵは終了処理を開始する。以下、終了処理を実行するソフトを終了処理ソフト、Ｐ／Ｃを実行するソフトをＰ／Ｃソフト、通常タスクを実行するソフトを制御アプリという。
（１）終了処理ソフトは、終了処理の実行中にＩＧ＝ＯＦＦからＩＧ＝ＯＮを検出すると「ＯＮ時刻」を記録する。なお、このＩＧ＝ＯＮにより、他のＥＣＵが処理を開始するまでのデッドラインが定まる。
（２）終了処理ソフトが終了すると、ＩＧ＝ＯＮを検出しているため、ＥＣＵはＣＰＵをリセットすることで、Ｐ／Ｃソフトを起動する。Ｐ／Ｃソフトはいくつかの（図では３つ）独立して実行可能な処理（Ｐ／Ｃ１〜３）に区分されている。Ｐ／Ｃソフトは、記録されているＯＮ時刻と現在時刻の差から、ＩＧ＝ＯＮからの経過時間を求める。また、全Ｐ／Ｃに必要な時間は固定なので、Ｐ／Ｃソフトにとって既知である。
（３）Ｐ／Ｃソフトは、デッドライン時間から経過時間を減じて残時間を算出する。そして、残時間内に終了するＰ／Ｃを選択し、選択したＰ／Ｃだけを実行する。図ではＰ／Ｃ1とＰ／Ｃ２が実行されている。

Ｐ／Ｃを実行した後は、ＥＣＵは制御アプリの起動を開始する。したがって、通常タスクは必ずデッドラインが到来する前に開始されることができる。また、部分的にでもＰ／Ｃを実行することでＥＣＵハード及びマイコンの信頼性確保を達成できる。

なお、後の実施例で説明するように、Ｐ／Ｃソフトは、通常タスクを開始した後、実行していないＰ／Ｃを実行することもできる。

図３は、本実施例のＰ／Ｃの実行方法が適用されたＥＣＵを含む電源供給システムの概略構成図の一例である。電源供給システムは、照合ＥＣＵ１１、電源制御ＩＣ１２、ＩＧリレー１４、及び、ＨＶ−ＥＣＵを有している。

照合ＥＣＵ１１は、電子キー（スマートキー（登録商標））を照合して、エンジンを始動させてよい状態であることを電源制御ＩＣ１２に通知する。すなわち、照合ＥＣＵ１１は、例えばカーテシスイッチによるドアの開閉により運転者が乗車したと推定すると、車内のアンテナで車内の電子キーと通信して、ＩＤコードを認証し認証が成立すると電源制御ＩＣ１２に車内照合が成立したことを通知する。

電源制御ＩＣ１２は、ブレーキペダルが踏み込み操作された状態でスタートスイッチ（ＩＧ）が押圧操作（ＯＮ）された事を検出すると、車内照合の成立を条件としてＩＧリレー１４をオンにする。これにより電源からＨＶ−ＥＣＵ１３に電力が供給される。また、電源制御ＩＣ１２は、ＨＶ−ＥＣＵ１３に起動信号を出力し、スタートスイッチが押圧操作（ＯＦＦ）されるとＨＶ−ＥＣＵ１３に終了信号を出力する。
ＨＶ−ＥＣＵ１３は、ハイブリッドシステムの全体を制御するＥＣＵであり、不図示のエンジンＥＣＵとモータＥＣＵと接続されている。ＨＶ−ＥＣＵ１３は、電源制御ＩＣ１２からの起動信号により起動する（リセットしてＰ／Ｃを実行）。ＨＶ−ＥＣＵ１３は、電源制御ＩＣ１２からの終了信号により終了処理を開始する。終了処理中に、起動信号を取得した場合、ＨＶ-ＥＣＵは起動信号の取得を記録しておくことになる。ＨＶ−ＥＣＵ１３が起動した後、ＨＶ−ＥＣＵ１３は不図示のリレーをオンにすることで、ハイブリッド系統の機器も起動するようになっている。

図４は、ＨＶ−ＥＣＵ１３の機能ブロック図の一例を示す。ＨＶ−ＥＣＵ１３は、ＣＰＵ２２、ＲＯＭ２３、ＲＡＭ、ＥＥＰＲＯＭ、Ｉ／Ｏ等がバスを介して接続されたコンピュータである。なお、ＣＰＵは好ましくはマルチコアを有しており、複数の処理を並行に実行することができる。

ＨＶ−ＥＣＵ１３は、ＣＰＵ２２がＲＯＭ２３に記憶されたプログラムを実行することにより実現される、初期タスク実行部３１、通常タスク実行部３２、及び、終了処理部３３を有する。なお、ＲＯＭ２３にはＰ／Ｃソフト、制御アプリ、及び、終了処理ソフトが記憶されており、初期タスク実行部３１はＰ／Ｃソフトの実体、通常タスク実行部３２の制御アプリの実体、終了処理部３３は終了処理ソフトの実体とする。また、初期タスク実行部３１は、タスク制御部３４を有する。なお、これらの一部以上をハードウェアにより実現してもよい。

ＨＶ−ＥＣＵ１３は、エンジンが出力すべき動力、モータが出力すべき動力、制動時の回生制動量、等を演算する処理を行う。これらはＨＶ−ＥＣＵ１３が一般に行うタスクであり通常タスクに相当する。通常タスク実行部３２は、図１にて説明したように機能統合により統合されたＣＡＮゲートウェイに関する処理を行う。また、通常タスク実行部３２は、一般的な処理として、アクセルペダル開度、ブレーキペダルの踏み込み量、シフトポジション、モータジェネレータを流れる電流値、モータジェネレータの回転速度に基づき、モータジェネレータＭＧ１，ＭＧ２の３相コイルに流す電流を決定し、決定した電流値に応じた駆動信号をインバータへ出力する。

また、通常タスク実行部３２は、同様の車両状態に基づき、エンジンによる動力が必要と判断すれば、エンジンが出力すべき動力を演算してエンジンＥＣＵに指示する。また、通常タスク実行部３２は、ブレーキペダルの踏み込み量によって車両の減速を検知すると、回生エネルギーを効率的に回収するため、変速機における減速比を高くする。また、ブレーキペダルの踏み込み量に基づいて要求制動力を演算し、要求制動力と、ＳＯＣ（Ｓｔａｔｅ Ｏｆ Ｃｈａｒｇｅ）と、回転速度とに基づいて、モータジェネレータの回生量を演算し、ブレーキアクチュエータが提供すべき回生量をブレーキＥＣＵに指示する。

通常タスク実行部３２は、このような処理を並行的に実行しており、各処理は制御アプリとして分離可能であるか、又は、少なくともＣＰＵ２２が判別できるようになっている。通常タスク実行部３２は、初期タスク実行部３１がＰ／Ｃを実行した後、例えばタスク制御部３４に呼び出されることで開始され、通常タスクを開始する。

なお、各通常タスクは、上記のように他のＥＣＵとの関係で、ＩＧ＝ＯＮを基準に実行を開始しなければならないデッドラインが決まっている。デッドラインは例えば２４０ミリ秒であるが、通常タスク毎に異なる場合もある。

初期タスク実行部３１は、ＨＶ−ＥＣＵ１３のハードが正常か否かをチェックするＰ／Ｃを実行する。Ｐ／Ｃとしては、例えば、リセット回路２１のチェック、ＲＯＭチェック、ＲＡＭチェック、チェックSUM、基板上の各チップ間の通信のチェック等が挙げられる。

リセット回路２１のチェックは、例えば、ＣＰＵ２２から所定の信号を送信した際に実際にＣＰＵ２２がリセットされるか否かをチェックする処理である。ＲＯＭチェックやＲＡＭチェックは、ＲＯＭからデータが正常に読み出せるか否か、書き込みした内容が正しく読み出させるか否か、等をチェックする処理である。チップ間の通信のチェックは、例えばリセット回路を管理している不図示の監視ICと通常タスクを実行するマイコン間の通信のチェックである。これらのＰ／Ｃは、初期タスク実行部３１が１つ以上を選択的に実行できるようにそれぞれが独立している。

終了処理部３３は、アクチュエータを安全に停止させる処理、ＥＣＵハードのアクセスを適切に終了させる処理、ＥＣＵやハードの設定を記憶する処理、等である。終了処理部３３が、行うべき終了処理の種類は有限であるが、実際にどの処理を行うかは、ＩＧ＝ＯＦＦの際のＨＶ−ＥＣＵ１３の状態に依存する。終了処理部３３はＨＶ−ＥＣＵ１３の状態に基づき、実行すべき全ての終了処理を実行する。

タスク制御部３４は、初期タスク実行部３１が実行するＰ／Ｃを決定する。タスク制御部３４は例えばＯＳのタスク制御機能を利用することもできる。本実施例では、タスク制御部３４は、ＩＧ＝ＯＮになったＯＮ時刻から終了処理が完了するまでの経過時間を、デッドラインから減じて、実行可能なＰ／Ｃを決定する。初期タスク実行部３１は決定されたＰ／Ｃを実行する。

このため、タスク制御部３４は、実行可能なＰ／Ｃを決定するため、各Ｐ／Ｃの実行予想時間を記憶している。
図５は各Ｐ／Ｃの実行予想時間を示す図の一例である。例えば、各Ｐ／Ｃの実行予想時間の合計が、デッドラインから経過時間を減じた残時間よりも長い場合、全てのＰ／Ｃは実行できないことが分かる。

図２に示したように、本実施例のＨＶ−ＥＣＵ１３は、搭載される通常タスクのデッドラインまでにＰ／Ｃが完了できないと予想した場合、デッドラインまでの時間に応じてＰ／Ｃを部分的に実行する。図２の上段は従来の処理におけるタイミングチャート図であり、終了処理が長引いた後、ＨＶ-ＥＣＵ１３が実行すべきＰ／Ｃを３つ実行することで、デッドラインまでに通常タスクが開始できなったことを示している。

これに対し、図２の下段のタイムチャート図では、ＨＶ−ＥＣＵ１３が実行するＰ／Ｃを２つに制限したことで、デッドラインまでに通常タスクが開始されていることを示している。このような処理を実現するため、ＨＶ−ＥＣＵ１３は、以下の処理を実行する。

図６は、ＨＶ−ＥＣＵ１３がＰ／Ｃと通常タスクを実行する手順を示すフローチャート図の一例である。図６では、初期タスク実行処理（Ｓ２００）、通常タスク実行処理（Ｓ３００）、及び、終了処理（Ｓ４００）の順に記述されている。これらの処理は、繰り返し実行の必要性が判断され、必要な処理のみが実行される。

図７（ａ）〜（ｃ）は初期タスク実行処理、通常タスク実行処理、及び、終了処理の手順を示すフローチャート図の一例である。すでに、初期タスク実行処理と通常タスク処理はすべて起動され、終了処理が起動されたものとして説明する。

ＩＧ=ＯＦＦになると図７（ｃ）のステップＳ４１０の判定がＹｅｓとなる。終了処理部３３は、終了処理の間（Ｓ４１０のＹｅｓ）、ＩＧリレー１４の状態がＩＧ＝ＯＦＦからＩＧ＝ＯＮへ操作されたか否かを判定している（Ｓ４２０）。

ＩＧ＝ＯＮになった場合（Ｓ４２０のＹｅｓ）、終了処理部３３はＩＧ＝ＯＦＦからＩＧ＝ＯＮへ操作されたＯＮ時刻を記録する（Ｓ４３０）。その後、終了処理部３３は、引き続き終了処理を実施する（Ｓ４４０）。

そして、終了処理が完了しない場合（Ｓ４５０のＮｏ）、処理はステップＳ２００から繰り返されるがＳ２００、Ｓ３００が実行されることはなく、引き続き終了処理のＳ４００においてＳ４１０の判定がＹｅｓとなる。

終了処理が完了すると（Ｓ４５０のＹｅｓ）、例えばＯＮ時刻が記録されていることからＨＶ-ＥＣＵの起動が必要だと判断して、終了処理部３３はリセット回路２１により自身をリセットする。これにより、ＨＶ−ＥＣＵ１３は再起動し、初期タスク実行部３１、通常タスク実行部３２等が起動される（Ｓ４６０）。具体的には、ＣＰＵ２２はＲＯＭ２３の予め定められたブート部のアドレスをプログラムカウンタに設定し、ブートプログラムを実行する。ブートプログラムは、ＣＰＵ２２にパラメータや定数を初期値として設定する。ブートプログラムは、まず、初期タスク実行部３１のアドレスをプログラムカウンタに設定し、以降は初期タスク実行部３１やタスク制御部３４の処理が開始する。

図７（ａ）の処理に移動し、まず、初期タスク実行部３１は、プログラムの初回起動か否かを判定する（Ｓ２１０）。プログラムの初回起動とは、ＩＧ=ＯＮ後、初めて初期タスク実行処理等が実行されたことをいう。この判定は、Ｐ／Ｃがすでに実行されたか否かを判定するための処理であり、次術する初期タスクテーブルに登録されたＰ／Ｃに実行フラグが登録されているか否かにより判定される。

初期タスク実行処理が初回起動の場合（Ｓ２１０のＹｅｓ）、タスク制御部３４は、初期タスクテーブルにＰ／Ｃを登録する（Ｓ２２０）。初期タスク実行部３１は、実行可能なＰ／Ｃを決定し初期タスクテーブルに登録する。
図８は、タスク制御部３４が、実行可能なＰ／Ｃを決定し初期タスクテーブルに登録する手順を示すフローチャート図の一例である。すでに説明したように、終了処理部３３が電源制御ＩＣ１２から起動信号が入力された時の時刻（絶対時刻）をＲＯＭ２３等に記憶している。本実施例ではミリ秒単位の精度が必要なので、絶対時刻ではミリ秒単位の精度がない場合、終了処理部３３は、クロックなどで増減するタイマをセットしてもよい。タスク制御部３４は、クロック周波数とタイマの値から経過時間をミリ秒レベルで算出することができる。

タスク制御部３４は、ＯＮ時刻又はタイマを参照して、ＩＧ=ＯＮからの経過時間T１を算出する（Ｓ１０）。

次に、予め記憶しているデッドラインTdから経過時間T1を減算して残時間を算出する（Ｓ２０）。残時間＝Td−T1
各Ｐ／Ｃの実行予測時間を読み出し合計してその時間を合計実行予測時間とする。タスク制御部３４は、合計実行予測時間が残時間よりも大きいか否かを判定する（Ｓ３０）。

合計実行予測時間が残時間よりも大きくない場合（Ｓ３０のＮｏ）、全てのＰ／Ｃを実行できることになるので、タスク制御部３４は初期タスクテーブルに全てのＰ／Ｃを登録する（Ｓ４０）。

合計実行予測時間が残時間よりも大きい場合（Ｓ３０のＹｅｓ）、初期タスク実行部３１は全てのＰ／Ｃを実行できないので、タスク制御部３４は実行すべきＰ／Ｃを決定する（Ｓ５０）。

決定方法については後の実施例にて説明するが、例えば、タスク制御部３４は、最も優先度の高い２つのＰ／Ｃの実行予測時間を読み出したり、ランダムに２つのＰ／Ｃの実行予測時間を読み出し、その合計実行予測時間が残時間よりも大きいか否かを判定する。合計実行予測時間が残時間よりも大きくない場合、この２つのＰ／Ｃを実行できることになるので、タスク制御部３４は初期タスクテーブルに、２つのＰ／Ｃを登録する。

合計実行予測時間が残時間よりも大きい場合、タスク制御部３４は２つのＰ／Ｃは実行できないと判定し、ランダムに１つのＰ／Ｃの実行予測時間を読み出し、その実行予測時間が残時間よりも大きいか否かを判定する。実行予測時間が残時間よりも大きくない場合、このＰ／Ｃを実行できることになるので、タスク制御部３４は初期タスクテーブルにこのＰ／Ｃを登録する。

１つのＰ／Ｃでも実行予測時間が残時間よりも大きい場合、Ｐ／Ｃを実行する余裕がないとして、タスク制御部３４は初期タスクテーブルにＰ／Ｃを登録しない。
図７（ａ）に戻り、初期タスク実行部３１は初期タスクテーブルに登録されたＰ／Ｃをすべて実行する（Ｓ２３０）。こうすることで、デッドラインまでにＰ／Ｃを実行することができた。

Ｐ／Ｃの実行が完了すると、通常タスク実行部３２が通常タスクを開始する。図７（ｂ）の処理に移り、通常タスク実行部３２は、起動していない通常タスクがあるか否かを判定する（Ｓ３１０）。

起動していない通常タスクがある場合（Ｓ３１０のＹｅｓ）、通常タスク実行部３２は記憶されているＯＮ時刻から現在時刻までの経過時間を算出する（Ｓ３２０）。

通常タスク実行部３２は、起動していない通常タスクのうち最も近いデッドラインと、経過時間を比較する（Ｓ３３０）。

通常タスク実行部３２は、その通常タスクのデッドライン時刻が到来したか否かを判定する（Ｓ３４０）。この判定は、例えば、デッドラインから経過時間を減じた値が所定値以下になったことを基準とする。なお、本実施例ではデッドライン時刻の到来を待たずに、通常タスクを実行してもよい。

通常タスクのデッドライン時刻が到来した場合（Ｓ３４０のＹｅｓ）、通常タスク実行部３２はデッドラインになった通常タスクを実行する（Ｓ３５０）。通常タスク実行部は通常タスクの起動を繰り返して、すべての通常タスクを起動する。

以上のようにして、ＨＶ−ＥＣＵ１３はＰ／Ｃを必ずデッドラインまでに終わらせることができる。1つもＰ／Ｃが実行できないことは希なので、ＨＶ−ＥＣＵ１３は実際には1つ以上のＰ／Ｃを実行できるとしてよい。したがって、ＥＣＵや関連するハードウェアが正常であることを確認でき、信頼性を確保することができる。

実施例１では、全てのＰ／Ｃを実行できない場合、タスク制御部３４が優先度順やランダムにＰ／Ｃを決定した。しかしこの方法では、実行されるＰ／Ｃに偏りが生じるおそれもあるため、実行すべきＰ／Ｃは信頼性が確保できるように恣意的に決定することが好ましい。

そこで、本実施例では、全てのＰ／Ｃを実行できない場合、実行回数の最も少ないＰ／Ｃを選択するＨＶ−ＥＣＵ１３について説明する。

図９は、ＨＶ−ＥＣＵ１３のタイミングチャート図の一例を示す。図９において図２と同一部の説明は省略する。図２と同様に、Ｐ／Ｃを決定することで、デッドラインまでにＰ／Ｃを終了させることができる。

図１０は、実行回数テーブルの一例を示す。実行回数テーブルは、例えばＲＯＭ２３に記憶されている。タスク制御部３４は、実行するＰ／Ｃを決定して初期タスクテーブルに登録した際又はＰ／Ｃの実行が完了する毎、実行回数テーブルに登録されているＰ／Ｃの実行回数を１つ大きくする。これにより、タスク制御部３４は、次回、実行するＰ／Ｃを決定する際、実行回数の最も少ないＰ／Ｃを実行することができる。

図１１は、初期タスク実行部３１が実行するＰ／Ｃを決定する手順を示すフローチャート図の一例である。通常タスク実行処理と終了処理については実施例１と同様なので省略する。

図１１の処理では、ステップＳ３２がある点が図８と異なる。ステップＳ３２においてタスク制御部３４は、実行回数テーブルを読み出す。図１０の実行回数テーブルでは、Ｐ／Ｃ１が１３回、Ｐ／Ｃ２が１１回、Ｐ／Ｃ３が１２回、それぞれ実行されている。このような場合、タスク制御部３４は、全てのＰ／Ｃを実行できないと判定すると、２つの実行回数の合計が最も少ない組み合わせであるＰ／Ｃ２とＰ／Ｃ３の合計実行予測時間を残時間と比較する。合計実行予測時間が残時間よりも大きくな場合、タスク制御部３４はこの２つのＰ／Ｃを実行するＰ／Ｃに決定する。

合計実行予測時間が残時間よりも大きい場合、別の組み合わせで同様の判定を行ってもよいが、その２つのＰ／Ｃが実行できると判定され、初期タスク実行部３１が実行すると、各Ｐ／Ｃ間の実行回数の差が増大することになる。しかしながら、可能な限りＰ／Ｃを処理することでＨＶ−ＥＣＵ１３の信頼が増すとも考えられる。したがって、別の組み合わせで同様の判定を行うか否かはＰ／Ｃの実行ポリシーによって決定することができる。

２つのＰ／Ｃの合計実行予測時間が残時間よりも大きい場合、タスク制御部３４は、実行回数が最も少ないＰ／Ｃ２の実行予測時間を残時間と比較する。実行予測時間が残時間よりも大きくない場合、タスク制御部３４はこのＰ／Ｃを実行するＰ／Ｃに決定する。１つのＰ／Ｃも実行できないことは少ないので、最も実行回数が少ないＰ／Ｃを実行することで、各Ｐ／Ｃの実行回数を均等化させることができる。

〔変形例〕
実行回数テーブルに過去の全ての実行回数を登録するのでなく、過去のＰ／Ｃの実行機会のうち最新の所定回数から実行回数を求めてもよい。なお、Ｐ／Ｃの実行機会とは、ＨＶ−ＥＣＵ１３が再起動された回数である。

図１２は、この変形例の実行回数テーブルの一例を示す。この実行回数テーブルには、Ｐ／Ｃ毎に、過去の最新の１０回の再起動のうち、実際に実行されたＰ／Ｃが記録（“○”により示す）される。また、過去の最新の１０回の再起動において、各Ｐ／Ｃが実行された回数が記録されている。実行回数テーブルはリングバッファのように、過去１０まで記録すると記録先が過去１に戻るので、最後の記録先が明示されている（図では過去３が最後の記録先であることを下線で示すが、実際には実行回数テーブルの記録先を示すアドレスやポインタで示される。）。

タスク制御部３４は、実行するＰ／Ｃを決定した際、最後の記録先の次の記録先のＰ／Ｃに「○」を登録する。そして、Ｐ／Ｃ毎に実行回数をカウントし、各Ｐ／Ｃが実行された合計を更新する。タスク制御部３４は、フローチャート図のステップＳ３２において、実行回数テーブルを読み出し、すでに説明したようにして実行するＰ／Ｃを決定する。

このように、最新の履歴を参照して実行すべきＰ／Ｃを決定することで、その時点でのＨＶ−ＥＣＵ１３の信頼性を確実に検出し、効果的に信頼性を確保することができる。

これまではデッドラインは制御アプリに共通であるかのように説明したが、デッドラインは他のＥＣＵが実行するプログラムとの関係により定まることが多いので、実際には複数の制御アプリのデッドラインが異なることもある。

図１３は、ＨＶ−ＥＣＵ１３のタイミングチャート図の一例を示す。図１３において図２と同一部の説明は省略する。図１３の下段では、通常タスクＢと通常タスクＡ,Cとでデッドラインが異なっている。この場合、タスク制御部３４は、最もデッドラインが近い制御アプリBのデッドラインに対し、全てのＰ／Ｃが実行できるか否か、及び、実行できない場合はどのＰ／Ｃを実行するかを決定する必要がある。

ここで、各通常タスクには関連の強いＰ／Ｃが存在する。通常タスクによっては、ＥＥＰＲＯＭへの書き込み、特定のICの動作、ADコンバータの変換など、制御アプリが必要とするハードウェアリソースが異なるためである。したがって、デッドラインが最も近い通常タスクに関連するＰ／Ｃを優先して実行すれば、よりデッドラインが遅い制御アプリに関連するＰ／Ｃを実行する余裕が生じることが期待できる。

各通常タスクのデッドライン及び通常タスクと関連の強いＰ／Ｃは固定であるので、この情報を使えば、優先的に実行すべきＰ／Ｃを決定することができる。
図１４（ａ）は各通常タスクのデッドラインと、通常タスクと関連の強いＰ／Ｃを示す図の一例である。例えば、通常タスクＡのデッドラインはＴａミリ秒であり、関連の強いＰ／ＣはＰ／Ｃ１〜３である。通常タスクＢのデッドラインはＴｂミリ秒であり、関連の強いＰ／ＣはＰ／Ｃ１、２である。通常タスクＣのデッドラインはＴｃミリ秒であり、関連の強いＰ／ＣはＰ／Ｃ３である。

説明のため、Ｔｂ＜Ｔａ、Ｔｃとする。したがって、通常タスクＢのデッドラインが最も短いので、通常タスクＢと関連が強いＰ／Ｃ１，２を優先的に実行すべきであることが分かる。タスク制御部３４は、このようにして決定されたＰ／Ｃの実行順序テーブルを記憶している。

図１４（ｂ）は実行順序テーブルの一例を示す。実行順序テーブルはＲＯＭ２３に記憶されている。実行順序テーブルには、デッドラインが最も短い通常タスクＢと関連が強いＰ／Ｃ１，２が、実行順番の１番と２番になっている。タスク制御部３４は、実行すべきＰ／Ｃを決定する際、実行順序テーブルを参照して実行するＰ／Ｃを決定する。こうすることで、デッドラインが短いＰ／Ｃを優先的に実行することができる。

図１５は、ＨＶ−ＥＣＵ１３が実行するＰ／Ｃを決定する手順を示すフローチャート図の一例である。図１５の処理では、ステップＳ１０の処理は図８と同様である。

Ｓ１２において、タスク制御部３４は実行順序テーブルを読み出す（Ｓ１２）。タスク制御部３４は実行順序テーブルを用いて実行すべきＰ／Ｃを決定する。タスク制御部３４は、まず実行順序テーブルのすべてのＰ／Ｃのから実行順序が一番のＰ／Ｃを特定する。

そのＰ／ＣのデッドラインTdを読み出し、経過時間T１を減算して残時間を算出する（Ｓ２０）。次に、タスク制御部３４は特定したＰ／Ｃの実行予想時間を読み出す。

タスク制御部３４は、実行予測時間が残時間よりも大きいか否かを判定する（Ｓ３０）。 実行予測時間が残時間よりも大きくない場合（Ｓ３０のＮｏ）、タスク制御部３４はそのＰ／Ｃをデッドラインまでの実行できると判定して、初期タスクテーブルに登録する（Ｓ５２）。この場合、初期タスク実行部３１は初期タスクテーブルに登録されたＰ／Ｃから順次、実行する。

１つのＰ／Ｃの実行後、処理はステップＳ１０に戻り、タスク制御部３４は実行順が２番目以降のＰ／Ｃについて同様の処理を繰り返す。これにより、デッドラインが近い制御タスクと関連の大きい順にＰ／Ｃを実行することができる。

なお、実行予測時間が残時間よりも大きい場合（Ｓ３０のＹｅｓ）、デッドラインまでにＰ／Ｃを実行完了できないので、図１５の処理は終了する。

本実施例のＨＶ−ＥＣＵ１３は、通常タスクのデッドラインと通常タスクに関連の強いＰ／Ｃを考慮して実行順序を決定し、Ｐ／Ｃ毎にデッドラインまでの残時間を算出するので、優先順位の高いＰ／Ｃを優先的に実行でき、また、デッドラインの遅いＰ／Ｃを実行する機会を増やすことができる。

実施例３では実行順序テーブルに基づきデッドラインの近い通常タスクと関連の強いＰ／Ｃを優先的に実行することができるが、実行順序テーブルだけに基づいてＰ／Ｃを決めると、実行されない又は実行回数が極端に少ない通常タスクが生じるおそれがある。

そこで、本実施例では、実施例２と同様に実行回数テーブルを利用して、実行回数が規定回数を満たさないＰ／Ｃは、実行を中止することなく実行するＨＶ−ＥＣＵ１３について説明する。なお、実行回数テーブルは過去の全ての実行回数を登録されていてもよいし、最新の所定回数の実行回数だけが登録されていてもよい。

図１６はタイミングチャート図の一例である。図１６の中段は実施例３と同様のタイミングチャート図である。すなわち、デッドラインが最も近い通常タスクＢに関連するＰ／Ｃのみが優先して実行されている。これに対し、図１６の下段は、Ｐ／Ｃ３の実行回数が規定回数を満たしていないため、デッドラインが最も近い通常タスクＢよりも優先して、Ｐ／Ｃ３が実行されている。このため、下段が上段と同様のタイミングチャート図となるが、規定回数を満たさないＰ／Ｃを実行することで、ＨＶ−ＥＣＵ１３の信頼性を確保できる。

図１７は、ＨＶ−ＥＣＵ１３が実行するＰ／Ｃを決定する手順を示すフローチャート図の一例である。ステップＳ３０において実行予測時間が残時間よりも大きくない場合（Ｓ３０のＮｏ）、タスク制御部３４は、実行回数テーブルを読み出し（Ｓ３２）、そのＰ／Ｃを初期タスクテーブルに登録する（Ｓ５２）。

実行予測時間が残時間よりも大きい場合（Ｓ３０のＹｅｓ）、タスク制御部３４は、実行回数が規定回数を満たしていないＰ／Ｃがあるか否かを判定する（Ｓ４２）。初期タスク実行部３１が実行回数の少ない順にＰ／Ｃを実行しても規定回数を満たさない状況は、例えば、車両の出荷直後や初期状態へのリセット後に生じうる。

ここで、過去の全ての実行回数を規定回数と比較すると、Ｐ／Ｃに実行頻度が少ないものがあっても規定回数以上実行されていると判定される。これを防ぐため、実行回数テーブルに過去の全ての実行回数が記録されている場合、タスク制御部３４は、最高の実行回数を有するＰ／Ｃの実行回数Nmaxに対する他の処理タスクの実行回数Nの比率を求め、比率が規定値N0を満たすか否かに基づき、実行頻度の少ないＰ／Ｃを特定する。

N／Nmax×１００ ＞ 規定値N0（例えば、７０％）
なお、実行回数テーブルに過去の所定回数の実行回数が記録されている場合、規定回数（例えば5回）と各Ｐ／Ｃの実行回数を比較すればよい。

実行回数が規定回数を満たしていないＰ／Ｃがある場合（Ｓ４２のＹｅｓ）、タスク制御部３４は、その全てのＰ／Ｃを実行すると決定する（Ｓ４４）。そして、初期タスク実行部３１は、デッドラインと無関係に全てのＰ／Ｃを実行する。

実行回数が規定回数を満たしていないＰ／Ｃがない場合（Ｓ４２のＮｏ）、図１７の処理は終了し、通常タスクが開始される。

本実施例によれば、Ｐ／Ｃに一定の実行回数がない場合、通常タスクを遅らせてもＰ／Ｃを実行するので、ＨＶ−ＥＣＵ１３の信頼性を確保できる。

これまでの実施例では、ＨＶ−ＥＣＵ１３が通常タスクの実行を開始した後は、Ｐ／Ｃを実行しないことを前提に説明した。しかし、Ｐ／Ｃは通常タスクを実行した後でも実行することができるので、通常タスクを開始した後、Ｐ／Ｃを実行することでＨＶ−ＥＣＵ１３の信頼性を確保することができる。

図１８は、ＨＶ−ＥＣＵ１３のタイミングチャート図の一例を示す。図１８において図２と同一部の説明は省略する。図１８の下段では、これまでの実施例と同様に一部のＰ／Ｃ１，２のみが実行されているが、その後、Ｐ／Ｃ３が通常タスクＢと並行に実行されている。Ｐ／Ｃ３は、通常タスクＡと関連の強いＰ／Ｃであるが、通常タスクＡは、Ｐ／Ｃ３の後に実行すれば、通常タスクＡに対するＨＶ−ＥＣＵ１３の信頼性を少なくとも確保することができる。

なお、通常タスクＢとＰ／Ｃ３の並行処理は、ＨＶ−ＥＣＵ１３の資源を時分割したり、ＣＰＵ２２がマルチコア又はマルチCPUを有していることで実現される。

図１９（ａ）〜（ｃ）はＨＶ−ＥＣＵ１３がＰ／Ｃと通常タスクを実行する手順を示すフローチャート図の一例である。図１９（ｃ）は図７（ｃ）と同じものであるので図１９（ａ）（ｂ）について説明する。

図１９（ａ）は初期タスクの実行手順を示すフローチャート図の一例である。まず、初期タスク実行部３１は、プログラムの初回起動か否かを判定する（Ｓ２１０）。判定方法は図７と同じである。

初期タスク実行部３１が初回起動の場合（Ｓ２１０のＹｅｓ）、初期タスク実行部３１は、初期タスクテーブルにＰ／Ｃを登録する（Ｓ２４０）。ここで登録するＰ／Ｃは実行順であるとするので、初期タスク実行部３１は例えば、実行順序テーブルを参照し、一番目のＰ／Ｃから初期タスクテーブルに登録する。

初期タスク実行部３１は、一番目のＰ／Ｃが未完了か否かを判定する（Ｓ２５０）。未完了の場合（Ｓ２５０のＹｅｓ）、タスク制御部３４は、ＯＮ時刻又はタイマを参照して、ＩＧ=ＯＮからの経過時間T１を算出する（Ｓ２６１）。

次に、予め記憶しているデッドラインTdから経過時間T1を減算して残時間を算出する（Ｓ２６２）。残時間＝Td−T1
タスク制御部３４は、実行予測時間が残時間よりも大きいか否かを判定する（Ｓ２６３）。

実行予測時間が残時間よりも大きくない場合（Ｓ２６３のＮｏ）、このＰ／Ｃを実行できることになるので、タスク制御部３４は初期タスクテーブルにＰ／Ｃを登録する（Ｓ２６４）。

実行予測時間が残時間よりも大きい場合（Ｓ２６３のＹｅｓ）、初期タスク実行部３１はこのＰ／Ｃを実行できないので、図１９（ａ）の処理は終了する。

次に、タスク制御部３４は実行中のＰ／Ｃが完了したか否かを判定する（Ｓ２７０）。実行中のＰ／Ｃが完了した場合（Ｓ２７０のＹｅｓ）、タスク制御部３４は、実行順序テーブルの次のＰ／Ｃを初期タスクテーブルに登録する（Ｓ２８０）。殆どの場合、初期タスクテーブルの最初のＰ／Ｃは実行されると考えらえる。

次に、処理は図１９（ｂ）に移動するが、図１９（ｂ）の処理にてデッドラインに到達していなければ（Ｓ３４０のＮｏ）、Ｐ／Ｃがすべて完了していない限り（Ｓ３６０のＮｏ）、処理は図１９（ａ）に戻る。よって、順次、P／Cが実行されていく。

また、図１９（ｂ）の処理にてデッドラインに到達した場合（Ｓ３４０のＹｅｓ）、通常タスクが実行されるが（Ｓ３５０）、Ｐ／Ｃがすべて完了していない限り（Ｓ３６０のＮｏ）、やはり処理は図１９（ａ）に戻る。よって、順次、通常タスクとP／Cが並行的に実行されていく。

なお、Ｓ3４0において、通常タスク実行部は、最も短いデッドラインから現在の経過時間を減じた残時間が、Ｐ／Ｃの予想実行時間よりも長いか否かに基づき、デッドラインの到来を判定する。こうすることで、Ｐ／Ｃの実行により通常タスクの実行が遅れることを防止できる。

このように、１つのＰ／Ｃを実行する毎に、通常タスクのデッドラインが到来したか否かを判定し、デッドラインが到来した場合は通常タスクを実行し、Ｐ／Ｃも平行に実行することで、通常タスクのデッドラインを守りながら、すべてのＰ／Ｃを実行できる。

実施例５では、Ｐ／Ｃの実行順を実行順序テーブルに従うとして説明したが、本実施例では、通常タスクのリスクランクに応じた順番にＰ／Ｃを実行するＨＶ−ＥＣＵ１３について説明する。

図２０は、リスクランクテーブルの一例を示す。リスクランクテーブルは、通常タスクとＰ／Ｃの組み合わせ毎に、リスクランクを登録したテーブルである。例えば、通常タスクＡについて次のようにリスクランクが登録されている。
通常タスクＡとＰ／Ｃ１：高（二重丸）
通常タスクＡとＰ／Ｃ２：中（丸）
通常タスクＡとＰ／Ｃ３：中（丸）
リスクが高いことはＰ／Ｃの必要性が高いことを意味する。なお、「−」はその通常タスクとＰ／Ｃの組では、通常タスクがＰ／Ｃを実行に影響を受けないことを意味している。

タスク制御部３４は、図２０のようなリスクランクテーブルを参照して、優先的に実行すべきＰ／Ｃを特定し、実行する。

図２１は、本実施例のタスク制御部３４がＰ／Ｃを実行する手順を示すフローチャート図の一例である。図２１は、図１９（ａ）の処理とほぼ同じであるが、ステップＳ２４０において、タスク制御部３４は、デッドラインが最も近い通常タスクのうち最もリスクランクが高いＰ／Ｃを特定する。以降の処理は実施例５と同様である。

本実施例によれば、タスク制御部３４は、通常タスクとの関係においてリスクランクの最も高いＰ／Ｃから実行することができる。

実施例５，６では通常タスクとＰ／Ｃの並列可能性を考慮しなかったが、通常タスクとＰ／Ｃには並列に実行できない組み合わせもある。例えば、Ｐ／Ｃの１つであるリセット回路２１のプライマリチェックは、リセット回路２１を駆動して強制リセットさせる処理なので、通常タスクも停止（リセットにより再起動）される。したがって、このような組み合わせでは（この場合、リセットと並列に実行可能な通常タスクはないが）、初期化タスクの優先度を下げ、並列に実行されないように担保する必要がある。

図２２は、通常タスクと並行に実行可能なＰ／Ｃが登録された実行可能初期タスクテーブルの一例を示す。図では「×」と記入されている通常タスクとＰ／Ｃの組み合わせにおいて、その通常タスクとＰ／Ｃを並列には実行できないことが示されている。なお、「×」となる組み合わせには、リセット回路２１の他、ハードウェアリソースの競合などがある。

図２３は、本実施例のタスク制御部３４がＰ／Ｃを実行する手順を示すフローチャート図の一例である。図２３は、図２１の処理と同様であるが、ステップＳ２４０において特定された、実行順序テーブルにおいて実行順が次のＰ／Ｃ又は最もリスクランクが高いＰ／Ｃに対し、タスク制御部３４は、そのＰ／Ｃと並列に実行できない通常タスクが実行されているか否かを判定する（Ｓ２４２）。すなわち、実行可能初期タスクテーブルを参照し、すでに実行されている全ての通常タスクについて特定したＰ／Ｃに「×」が登録されていないかどうかを確認する。

登録されていた場合は（Ｓ２４２のＹｅｓ）、ステップＳ２４０に戻り、タスク制御部３４は、再度、実行順序テーブルにおいて実行順が次のＰ／Ｃ又は最もリスクランクが高いＰ／Ｃを特定する。これを繰り返すことにより、通常タスクと並列に実行できるＰ／Ｃを特定することができる。

以上のように、本実施例のＨＶ−ＥＣＵ１３は、Ｐ／Ｃを実行する余裕がない場合でも、通常タスクのデッドラインと経過時間に応じてＰ／Ｃを実行できるので、部分的にでもＰ／Ｃを実行することができる。よって、ＥＣＵハード及びマイコンの信頼性確保を達成できる。また、通常タスクを開始した後、実行していないＰ／Ｃを実行することで、信頼性を確保することができる。

１１ 照合ＥＣＵ
１２ 電源制御ＩＣ
１３ ＨＶ−ＥＣＵ
１４ ＩＧリレー
２１ リセット回路
２２ ＣＰＵ
２３ ＲＯＭ
３１ 初期タスク実行部
３２ 通常タスク実行部
３３ 終了処理部
３４ タスク制御部

Claims (11)

1. 起動指示から起動開始までの期限が定められたタスクを実行する情報処理装置であって、
   前記タスクの開始までに実行すべき複数の初期処理タスク及び該初期処理タスク毎の予想実行時間が登録された初期処理タスクテーブルと、
   前記起動指示を受け付けた起動指示時刻を記録する起動指示時刻記録手段と、
   前記期限から前記起動指示時刻からの経過時間を減じた残時間と、前記予想実行時間を比較して、前記期限までに実行する前記初期処理タスクを決定するタスクスケジュール手段と、
   前記初期処理タスクを実行する初期処理タスク実行手段と、
   を有することを特徴とする情報処理装置。
2. 前記タスクの前に実行すべき前記初期処理タスク及び前記タスク毎の前記期限とに基づき、前記期限が短い順に前記タスクの前に実行すべき前記初期処理タスクが実行順に登録された実行順序テーブルを有し、
   前記タスクスケジュール手段は、前記実行順序テーブルに登録されている前記初期処理タスクの順に、該初期処理タスクの後に実行される前記タスクの前記期限から求められた前記残時間と前記初期処理タスクの前記予想実行時間を比較して、前記残時間内に実行可能な前記初期処理タスクを決定する、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記初期処理タスク毎の実行回数が登録された実行回数テーブルを有し、
   前記タスクスケジュール手段は、前記実行回数が最も少ない前記初期処理タスクを前記期限までに実行すると決定する、
   ことを特徴とする請求項１記載の情報処理装置。
4. 前記タスクスケジュール手段は、前記実行回数テーブルの前記実行回数を予め定められた規定回数と比較して、前記規定回数を満たしていない前記初期処理タスクがある場合、
   前記残時間が前記予想実行時間より短くても、前記タスクに優先して前記初期処理タスクを実行すると決定する、
   ことを特徴とする請求項１記載の情報処理装置。
5. 起動指示から起動開始までの期限が定められたタスクを実行する情報処理装置であって、
   前記起動指示を受け付けた起動指示時刻を記録する起動指示時刻記録手段と、
   前記タスクの開始までに実行すべき複数の初期処理タスク及び該初期処理タスク毎の予想実行時間が登録された初期処理タスクテーブルと、
   前記初期処理タスクが実行順に登録された実行順序テーブルと、
   前記実行順序テーブルに基づき決定した前記初期処理タスクの前記予想実行時間が、前記期限から前記起動指示時刻からの経過時間を減じた残時間以下の場合、前記実行順序テーブルに基づき決定した前記初期処理タスクを実行すると決定するタスクスケジュール手段と、
   前記初期処理タスクを実行する初期処理タスク実行手段と、
   前記期限が到来した前記タスクを実行するタスク実行手段と、
   ことを特徴とする情報処理装置。
6. 前記タスクスケジュール手段は、前記実行順序テーブルに基づき決定した前記初期処理タスクの前記予想実行時間が前記残時間よりも長い場合、前記実行順序テーブルに基づき決定した前記初期処理タスクを実行することなく、
   前記タスク実行手段が前記期限が到来した前記タスクを実行し、
   前記初期処理タスク実行手段と前記タスク実行手段が、前記初期処理タスクと前記タスクを時分割して実行する、
   ことを特徴とする請求項５記載の情報処理装置。
7. 前記実行順序テーブルには、前記タスクの前に実行すべき前記初期処理タスク及び前記タスク毎の前記期限とに基づき、前記期限が短い順に前記タスクの前に実行すべき前記初期処理タスクが実行順に登録されている、ことを特徴とする請求項５又は６記載の情報処理装置。
8. 起動指示から起動開始までの期限が定められたタスクを実行する情報処理装置であって、
   前記起動指示を受け付けた起動指示時刻を記録する起動指示時刻記録手段と、
   前記タスクの開始までに実行すべき複数の初期処理タスク及び該初期処理タスク毎の予想実行時間が登録された初期処理タスクテーブルと、
   前記タスクの機能上、必要性が高い順に前記初期処理タスクが登録されたリスクランクテーブルと、
   前記期限が短い順に特定した前記タスクにとって必要性が高い順に決定した前記初期処理タスクの前記予想実行時間が、前記期限から前記起動指示時刻からの経過時間を減じた残時間以下の場合、前記リスクランクテーブルに基づき決定した前記初期処理タスクを実行すると決定するタスクスケジュール手段と、
   前記初期処理タスクを実行する初期処理タスク実行手段と、
   前記期限が到来した前記タスクを実行するタスク実行手段と、
   ことを特徴とする情報処理装置。
9. 前記タスクと時間的に並行に実行可能な前記初期処理タスクが登録された実行可能初期タスクテーブルを有し、
   前記タスクスケジュール手段は、実行予定の前記初期処理タスクと並列に実行できない前記タスクが実行されている場合、前記初期処理タスクを決定しなおす、
   ことを特徴とする請求項５〜８いずれか１項記載の情報処理装置。
10. 前記起動指示時刻記録手段は、車両の駆動システムのスタートボタンのオフ信号により、車両状態に基づく終了タスクを実行する手段であり、
    前記終了タスクの実行中に、前記起動指示時刻記録手段が車両の駆動システムのスタートボタンのオン信号が検出された場合、
    前記起動指示時刻記録手段は、前記オン信号を前記起動指示として、前記終了タスクの実行後、当該情報処理装置をリセットする、
    ことを特徴とする請求項１〜９いずれか１項記載の情報処理装置。
11. 請求項１〜１０いずれか１項記載の情報処理装置が搭載された電子制御ユニット。

Images