JP2011216004A - マイクロプロセッサ、電子制御ユニット、実行比率切り替え方法 - Google Patents

Abstract

【課題】タスク内容に応じて複数のプログラムのＱｏＳを切り替え可能なマイクロプロセッサ等を提供する。
【解決手段】ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、ｎ個のプログラムを実行するマイクロプロセッサであって、ｎ個のプログラムそれぞれのメインタスク、及びアイドルタスクを記憶する記憶手段２４、ｎ個のプログラムのそれぞれの目標実行比率に基づき、ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段１６と、各ハードウェアスレッドによるｎ個のプログラムの実行アドレスと、記憶手段における各アイドルタスクのアドレス情報を比較した結果に基づくｎ個のプログラムの動作状況に応じた目標実行比率を前記スケジュール制御手段１６に指示するソフトウェア監視手段１８とを有する。
【選択図】図２

Description

本発明は、複数のハードウェアスレッドを備えたマイクロプロセッサ等に関し、特に、ハードウェアスレッド間の実行比率を制御可能なマイクロプロセッサ、電子制御ユニット及びアドレス変換方法に関する。

１つのマイクロプロセッサが複数のスレッド（プログラム）を同時並行的に実行するようなマルチスレッドが実現されるようになった。マルチスレッド型のマイクロプロセッサは、複数のスレッドをそれぞれ実行するので、スレッド間の実行比率を制御したい場合が少なくない。
例えば、マルチスレッドが可能なプロセッサにおいて、スレッドを切り替えるための技術が考案されている（例えば、特許文献１参照。）。特許文献１には、複数のプロセッサを有するプロセッサグループにおいて、各プロセッサに、スレッドごとのプロセッサ・リソース使用率をカウントするプロセッサ使用サイクル・カウンタが組み込まれたプロセッサグループが開示されている。

特表２００６−５２４３８０号公報

ところで、車両ではプロセッサが搭載された種々のＥＣＵ（Electronic Control Unit）を、ＨＭＴ（ハードウェアマルチスレッド）機能を有する１つ又は数個のＥＣＵに統合することが検討されている。統合前のあるＥＣＵで動作するプログラムが、優先度が高いメインタスクと優先度が低いアイドルタスクを有する場合がある（２つのタスクで１つのプログラムである）。統合前のＥＣＵは、一般的に、イベントが発生したり、周期タスク（メインタスクに含まれる）のタイミングが到来すると、メインタスクを開始し、優先度が高いメインタスクが終了した時点で優先度が低いアイドルタスクを実行する。アイドルタスクは、具体的な処理を受け持つわけではなく、メインタスクが実行されていない場合に、レジスタチェック、フェールセーフ処理、又は、無限ループによるメインタスクの待ち状態等を提供するタスクである。

ここで、２つのＥＣＵ_Ａ、ＥＣＵ_Ｂの機能を、ＨＭＴ型のマイクロプロセッサを持ったＥＣＵに統合した場合を考える。ＥＣＵ_Ａは、プログラムＡとしてメインタスクＡとアイドルタスクＡを有し、ＥＣＵ_ＢはプログラムＢとしてメインタスクＢとアイドルタスクＢを有する。ＭＨＴプロセッサを有する統合後の機能統合ＥＣＵは、プログラムＡとプログラムＢを同時並行的に実行する。すると、機能統合ＥＣＵは、プログラムＡのメインタスクＡとプログラムＢのアイドルタスクＢを同時並行に実行することもある。プログラムＢ内では、メインタスクＢがアイドルタスクＢよりも優先されるようにコーディングされているが、異なるプログラムに含まれるメインタスクＡとアイドルタスクＢには、メインタスクＡをアイドルタスクＢよりも優先させるような仕組みが含まれていない。その逆に、メインタスクＢとアイドルタスクＡにも、メインタスクＢをアイドルタスクＡよりも優先させるような仕組みも含まれていない。

上記のように、アイドルタスクＢは具体的な処理を行っていないので、プログラムＡとプログラムＢを統合した後、機能統合ＥＣＵ２００はメインタスクＡをアイドルタスクＢよりも、又は、メインタスクＢをアイドルタスクＡよりも、優先することが好ましい。このためには、例えば、機能統合ＥＣＵがメインタスクＡとアイドルタスクＢを同時並行して実行している間は、プログラムＡとプログラムＢのＱｏＳ（Quality of Service）を変える（例えば、プログラムＡ：８０％、プログラムＢ：２０％）ことが考えられる。

しかしながら、特許文献１に開示されたプロセッサグループのように、各プロセッサにプロセッサ使用サイクル・カウンタを搭載して、処理負荷を実行比率の変更のトリガーとすることは、却ってプロセッサの処理負荷が増大してしまうという問題がある。

また、プロセッサ使用サイクル・カウンタにより処理負荷を監視してプログラムの優先度を切り替えると、処理負荷の変動に起因してプログラムの切り替わりが頻繁に生じる可能性があり、オーバヘッドとなるという問題がある。すなわち、機能統合ＥＣＵでは非同期にイベントが発生するので、処理負荷に応じてプログラムＡとプログラムＢのＱｏＳを入れ替えると、本来の目的であるプログラムＡとプログラムＢの並行処理よりもＱｏＳの入れ替えにリソースが費やされるおそれがある。

また、例えば、ＯＳのスケジューラがイベントを取得するためのポーリングを実行することも考えられるが、ポーリングによるイベント検出は長い待ち時間が必要であるため、こちらもオーバーヘッドが大きくなるという不都合を生じさせるおそれがある。

本発明は、上記課題に鑑み、ＨＭＴ機能を有するマイクロプロセッサにおいて、独立したプログラムのタスク内容に応じてプログラムのＱｏＳを切り替え可能なマイクロプロセッサ、電子制御ユニット及び実行比率切り替え方法を提供することを目的とする。

上記課題に鑑み、本発明は、ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、ｎ個のプログラムを実行するマイクロプロセッサであって、ｎ個のプログラムそれぞれのメインタスク、及び、アイドルタスク、を記憶した記憶手段と、ｎ個のプログラムのそれぞれの目標実行比率に基づき、ｎ個のハードウェアスレッドに実行権を与えるスケジュール制御手段と、各ハードウェアスレッドによるｎ個のプログラムの実行アドレスと、記憶手段における各アイドルタスクのアドレス情報、を比較する比較手段と、比較手段の比較結果に基づき、ｎ個のプログラムの動作状況を監視し、該動作状況に応じた目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、を有する。
を有することを特徴とする。

ＨＭＴ機能を有するマイクロプロセッサにおいて、処理負荷やイベントを監視することなく、タスク内容に応じてプログラムのＱｏＳを切り替え可能なマイクロプロセッサ、電子制御ユニット及び実行比率切り替え方法を提供することができる。

ＥＣＵの機能統合を模式的に説明する図の一例である。 マイクロプロセッサの概略構成図の一例である。 ＨＭＴプロセッサであるマイクロプロセッサのＨＴを模式的に説明する図の一例である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である。 マイクロプロセッサの概略構成図の一例である（実施例２）。 レジスタに設定される値をアドレスマップにて説明する図の一例である。 スケジュールレジスタ１、スケジュールレジスタ２及びデフォルトレジスタに格納される値を模式的に示す図の一例である。 アドレス監視装置の機能を模式的に示す図の一例である。 プログラムＡ、Ｂの動作状況と、アドレス監視装置が出力する切り替え要求信号の関係の一例を示す図である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例２）。 マイクロプロセッサの概略構成図の一例である（実施例３）。 アドレスマップを説明する図の一例である。 アドレス監視装置の機能を模式的に示す図の一例である。 プログラムＡ、Ｂの動作状況と、アドレス監視装置が出力する切り替え要求信号の関係の一例を示す図である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例３）。 マイクロプロセッサの概略構成図の一例である（実施例４）。 ＯＳが提供するＨｏｏｋ処理を模式的に説明する図の一例である。 Ｈｏｏｋ監視装置の概略構成図の一例である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例４）。 マイクロプロセッサの概略構成図の一例である（実施例５）。 ＴａｓｋＩＤ監視装置の機能を模式的に示す図の一例である。 プログラムＡ、Ｂの動作状況と、ＴａｓｋＩＤ監視装置が出力する切り替え要求信号の関係の一例を示す図である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例５）。 マイクロプロセッサの概略構成図の一例である（実施例６）。 アドレス監視装置が記録した動作状況毎の負荷比の一例を模式的に示す図の一例である。 ＯＳによるスケジュールレジスタ１〜４への値の設定を模式的に説明する図の一例である。 切り替え要求信号を模式的に説明する図の一例である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例６）。 マイクロプロセッサの概略構成図の一例である。 ＴａｓｋＩＤ監視装置の機能を模式的に示す図の一例である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例７）。 マイクロプロセッサの概略構成図の一例である（実施例８）。 ＴａｓｋＩＤ監視装置の機能を模式的に示す図の一例である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例８）。 実施例９の課題を説明する図の一例である。 マイクロプロセッサの概略構成図の一例である（実施例９）。 ＴａｓｋＩＤ監視装置の機能を模式的に示す図の一例である。 比較器の比較によって得られる動作状況の一例を示す図である。 プログラムの動作状況とＱｏＳの関係の一例を示す図である（実施例９）。

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

本実施形態のマイクロプロセッサは、ハードウェアマルチスレッド（以下、ＨＭＴという）機能を有する。ＨＭＴについては後述する。マイクロプロセッサは、ハードウェアスレッド（以下、ＨＴという）を切り替えることで擬似的に同時に複数のプログラムを実行している。

そして、本実施形態のマイクロプロセッサの概略的な特徴は以下のようになる。
（１）各プログラムは、メインタスクとアイドルタスクを有するソフト構造になっている。
（２）ＨＴの切り替えを制御するスケジュール制御装置を有する。
（３）各プログラムのタスクの動作状況を監視するソフトウェア監視装置を有する。
（４）ソフトウェア監視装置はタスクの動作状況に基づき、プログラムＡとＢのＱｏＳ（Quality of Service）を切り替えるよう、スケジュール制御装置に通知する。

このように、ソフトウェア監視装置がプログラムの動作状況を監視するので、プログラムＡのメインタスクとプログラムＢのアイドルタスクが同時並行に実行される状況では、スケジュール制御装置は、プログラムＡの実行比率をプログラムＢよりも大きくするなど、ＱｏＳを変更することができる。よって、統合前の各ＥＣＵが実行していた各プログラムを、ＨＭＴ機能を有するＥＣＵに搭載しても、別々のプログラムのメインタスクとアイドルタスクのＱｏＳを適切に制御することができる。

また、ソフトウェアの開発時に、統合前の各ＥＣＵが実行していた各プログラムを、アイドルタスクが開始したことを検出できるように修正する必要もないので、機能統合ＥＣＵの開発コストを低減できる。

〔ＥＣＵの機能統合について〕
図１は、ＥＣＵの機能統合を模式的に説明する図の一例である。本実施形態では、複数のＥＣＵを１つのＥＣＵ（以下、機能統合ＥＣＵ２００という）に統合したこと（すること）を前提にする。統合前のＥＣＵが実行していたプログラムを実行する、機能統合ＥＣＵ２００の一連のハードウェアをＨＴという。

図１の左側に示すように、機能統合前はＥＣＵ_Ａ上でプログラムＡが動作しており、ＥＣＵ_Ｂ上でプログラムＡが動作する。それぞれのプログラムＡ、Ｂには車両制御に必要な演算や入出力制御を行うメインタスクＡ，Ｂと、メインタスクＡ，Ｂが処理を完了し次回、メインタスクＡ，Ｂが立ち上がるまで動作するアイドルタスクＡ，Ｂが存在する。

機能統合後は、図１の右側に示すように、１つの機能統合ＥＣＵ２００内でプログラムＡとＢが独立に実行される。プログラムＡを実行する一連のハードウェアがＨＴ０、プログラムＢを実行する一連のハードウェアがＨＴ１、である。それぞれＨＴ０，１は、プログラムＡとプログラムＢを擬似的に並行処理する。このため、外部からは、機能統合によるタイムラグが意識されることなく、１つの機能統合ＥＣＵ２００がＥＣＵ_ＡとＥＣＵ_Ｂの機能を不足なく提供できる。

なお、統合前のＥＣＵがＯＳ上でプログラムを実行する場合があるが、この場合は、ＯＳとプログラムが１つの“プログラム”となる。マイクロプロセッサ１００は、実行している命令がプログラムかＯＳなのかを区別せずに実行する。こうすることで、統合前のＥＣＵが実行するプログラムとＯＳの振る舞いをそのままマイクロプロセッサ１００に持ち込むことができる。したがって、プログラムはＯＳを含んでいてもよいし、ＯＳを含んでいなくてもよい。本実施形態では、プログラムという場合、ＯＳを含むか否かを問わない。

ＥＣＵの機能統合は、大幅なＥＣＵ開発費の削減を可能とする可能性が高く、車両の価格競争力という点からも重要な技術となる。例えば、機能統合において、開発済みのプログラムをそのまま（機能統合後の機能統合ＥＣＵ２００に搭載可能か否かを詳しく検証することなく）機能統合ＥＣＵ２００に搭載できれば、機能統合ＥＣＵ２００の開発費を削減できることが期待される。

ＨＭＴという技術は、従来、ソフトウェアにより実現していた複数プログラムの同時実行をハードウェアにより実現する。ハードウェアで実現することで、プログラムの切り替え時のオーバヘッドをほぼゼロにでき、結果的にリアルタイム性が厳しく要求される車両の機能統合ＥＣＵ２００にも実装できるようになり、複数のＥＣＵの機能統合が実現される。

なお、統合前のＥＣＵは、例えば、燃料噴射量、エンジン回転数、吸気バルブの開放時間、空燃比の決定等を決定するエンジンＥＣＵ、各輪のホイルシリンダ圧を決定するブレーキＥＣＵ、エンジンとモータそれぞれの出力トルク、運転モード（モータ運転モード、エンジン＋モータ運転モード）等を決定するハイブリッドＥＣＵ等である。なお、このようなリアルタイム性が強い制御系のＥＣＵだけでなく、ボディＥＣＵやナビゲーション用のＥＣＵを統合してもよい。

〔マイクロプロセッサ１００の構成〕
図２、３を用いて、マイクロプロセッサ１００について説明する。図２は、マイクロプロセッサ１００の概略構成図の一例を、図３はＨＭＴプロセッサであるマイクロプロセッサ１００のＨＴを模式的に説明する図の一例である。図２のマイクロプロセッサ１００は、統合前の２つのＥＣＵを統合した例を示すが、３以上のＥＣＵを統合することもできる。また、統合することなく１つのプログラムのみを実行してもよい。

マイクロプロセッサ１００は、命令フェッチバス２５を介して命令記憶部２３と、データアクセスバス２６を介してデータ記憶部２４と、それぞれ接続されている。図２のマイクロプロセッサ１００は、ＨＭＴ型のプロセッサである。図２のＨＭＴを簡単に説明すれば、命令バッファ１１（区別する場合、命令バッファ０，１という）と命令デコーダ１２（区別する場合、命令デコーダ０，１という）を接続するマルチプレクサ１９を、スケジュール制御装置１６が切替制御することで、ハードウェア的にプログラム（ＨＴ）を選択し、選択したＨＴにプログラムの実行権を与えるという処理の実行方法である。

図２，３に示すように、マイクロプロセッサ１００は、命令デコーダ０，１はレジスタ群０，１と接続されている。図４に示したように、命令バッファ０は命令デコーダ０と、命令デコーダ０はレジスタ群０と接続され、命令バッファ１は命令デコーダ１と、命令デコーダ１はレジスタ群１と接続される。

また、レジスタ群０，１はバス２２を介して演算器１４及びＬＳＵ１５と接続される。スケジュール制御装置１６はマルチプレクサ１９に接続され、パイプライン制御装置１７は命令デコーダ０，１、レジスタ群０，１、並びに、演算器１４及びＬＳＵ１５と接続されている。また、オフセットアドレス制御装置１８には、命令デコーダ０，１、パイプライン制御装置１７、並びに、演算器１４及びＬＳＵ１５と接続されている。

スケジュール制御装置１６は、マルチプレクサ１９を１クロックで切替制御できるので、プログラムの切り替え時のオーバヘッドはほぼ無視できる。

命令フェッチバス２５は、アドレスバスとデータバスを有し、命令記憶部２３に記憶された命令のアドレスをアドレスバスで指定して、読み出されたコード（例えば、全長３２bitの長さのオペコードとオペランド）を、データバスを介して命令バッファ０，１に供給する。命令記憶部２３は、機能統合ＥＣＵ２００ではフラッシュメモリなどの不揮発メモリであることが多い。なお、図３では命令記憶部２３とデータ記憶部２４が別体であるが、両者が一体の不揮発メモリに配置されることもある。

データアクセスバス２６には、バスブリッジが設けられており、バスブリッジを介してＲＡＭ（ＳＲＡＭ、ＤＲＡＭ等の揮発メモリ）、周辺機器（Ａ／Ｄ変換器、シリアルポート等）と接続されている。ＲＡＭには制御信号となる電圧値が一次保存されたり、周辺機器にはセンサ類の出力が接続されている。なお、上記のように、データ記憶部２４が命令記憶部２３と一体の不揮発メモリとなっていることが多い。

命令バッファ０，１にはそれぞれＰＣ（プログラムカウンタ）が設けられている。命令バッファ０は、ＰＣが指定するアドレスの１以上のコードをＦＩＦＯにて記憶するバッファであり、命令バッファ１は、プログラムＢの１以上のコードをＦＩＦＯにて記憶するバッファである。

命令デコーダ１２は命令バッファ１１のコードのオペコードから命令を解読して演算の種類を特定し、オペランドから１つ以上のソースオペランド、演算結果の格納先等を解読する。オペコードの位置は先頭bitを基準にｎbitからｍbitのように仕様として定められている。解読結果は、命令デコーダ１２が属するＨＴのレジスタ群１３に格納される。

レジスタ群１３は、命令デコーダ１２の解読結果（命令の種別、１以上のソースオペランド、結果の格納場所等）、演算器の演算結果、ＬＳＵ１５がデータアクセスバス２６を介してデータ記憶部２４から読み出したデータ、及び、ＬＳＵ１５がデータ記憶部２４に格納するデータ、を一時的に記憶する複数のレジスタ（汎用レジスタやフラグレジスタ）を集積したものである。

演算器１４及びＬＳＵ１５はＨＴ０，１に対し共通に設けられている。演算器１４はオペコードの解読結果に応じて四則演算を行ったりレジスタ群１３のレジスタ操作を行う。また、演算器１４は演算結果をレジスタ群１３にライトバックする。ＬＳＵ１５はオペコードの解読結果がロード命令の場合、レジスタ群１３のソースオペランドが指示する変位量とレジスタ内容からアドレスを決定し、データアクセスバス２６を介してデータ記憶部２４からデータを読み出す。読み出したデータは、ソースオペランドが指示するレジスタに格納する。同様に、ＬＳＵ１５はオペコードの解読結果がストア命令の場合、レジスタ群１３のソースオペランドが指示する変位量とレジスタ内容からアドレスを決定し、ソースオペランドが指示するレジスタに格納されたデータを、決定したアドレスのデータ記憶部２４に記憶させる。

＜スケジュール制御＞
スケジュール制御装置１６は、各プログラムの実行比率が目標実行比率になるように命令の発行比率を制御する。具体的には、スケジュール制御装置１６はマルチプレクサ１９において命令バッファ０（１）と命令デコーダ０（１）を接続するか否か、を制御する。

実行比率は、ＨＴ０において例えば「実行される命令の数／単位時間」（＝ＩＰＣ：クロック単位の命令実行数）と、ＨＴ１におけるＩＰＣの比である。両者の命令の実行速度を比較する指標であればＩＰＣ以外の比から求めてもよい。

目標実行比率は、各プログラムに提供すべきＱｏＳにより予め定まっている。車両では、安全性を最重要視してプログラムの優先度が決まっており、この優先度はＥＣＵを機能統合しても変わらない。例えば、プログラムＡが単位時間にＡ個の命令の実行が保証されるべきであり、プログラムＢが単位時間にＢ個の命令の実行が保証されるべきであるなら、機能統合後もプログラムＡとプログラムＢの実行比率が保たれるべきだからである。統合前のプログラムＡ、Ｂの実行比率は開発者が決定するパラメータである。

ところで、パイプライン制御装置１７は、各命令のステージを制御しているので、どのプログラムの命令が完了したかを検出でき、単位時間の実行完了命令数を監視できる。これをスケジュール制御装置１６に通知すれば、スケジュール制御装置１６は予め既知の実行効率と比較して、各プログラムの命令の発行比率を制御できる。

しかしながら、車載される機能統合ＥＣＵ２００、特に制御用の機能統合ＥＣＵ２００は後からプログラムが追加されることはほとんどないので、単位時間の実行完了命令数を監視するまでもなく、例えば、車両の設計時にカウントした単位時間の実行完了命令数は、市中を走行中の車両でも大きく変わることはない。このため、フィードバック的な制御は不要であり、スケジュール制御装置１６は、車両の設計時に、統合前のプログラムＡ、Ｂの実行比率が保証されるように、目標実行効率になる命令の発行比率（目標発行比率）を定めておくことができる。なお、命令の種類によって実行完了するまでのクロック数が異なるので、発行比率と実行比率は一致しないが、この関係も調整して目標発行比率（＝ＱｏＳ）が定められる。以下の実施例を含め、スケジュール制御装置１６がいくつか異なるＱｏＳに目標発行比率を切り替えることが特徴となる。

また、目標発行比率は、例えば、単位時間のプログラムＡの命令の発行数と、プログラムＢの命令の発行数の比をいい、「３０：７０」「５０：５０」のように表すことができる。前者の場合、スケジュール制御装置１６は、１０回のクロックのうち３回、プログラムＡの命令を命令デコーダ０に読み出し、１０回のクロックのうち７回、プログラムＢの命令を命令デコーダ１に読み出す。なお、マイクロプロセッサ１００の性能が向上し、機能統合ＥＣＵ２００の実行速度が大きくなりすぎた場合、スケジュール制御装置１６は「２０：６０：２０（アイドル）」のように、マイクロプロセッサ１００が命令を実行しないアイドル状態のタームを設けることもできる。スケジュール制御装置１６には予めデフォルトの目標発行比率のＱｏＳが定められている。

目標発行比率に従い、スケジュール制御装置１６は、資源を割り当てるＨＴをクロック単位で制御しており、パイプライン制御装置１７に該ＨＴを通知している。こうすることで、パイプライン制御装置１７は、資源を割り当てられたＨＴのステージを制御しながら命令を実行できる。

＜パイプライン制御＞
パイプライン制御装置１７は、スケジュール制御装置１６から通知されたＨＴ毎に、命令バッファ１１から命令デコーダ１２へのコードの読み出し（命令フェッチ）、命令をデコードしてレジスタ群１３への書き込み（命令デコード）、命令の実行、メモリアクセス（四則演算ではなにもしないステージ）、レジスタ群１３へのライトバック、の各ステージの進行を制御する。すなわち、パイプライン制御装置１７は、あるクロックにおいて、命令nのライトバック，命令n＋１のメモリ・アクセス、命令n＋２の実行，命令n＋３の命令デコード、命令n＋４の命令フェッチを、同時に行う。したがって、１クロック毎に平均的に１つの命令の実行結果が得られる。

「ＨＴ毎に」とは、図３に示したように、命令バッファ０（１）と命令デコーダ１２がマルチプレクサ１９を介して接続された状態では、必ず、命令デコーダ１２とレジスタ群０（１）が接続されることを意味する。

パイプラインのステージはＨＴ毎に制御する必要があるため、パイプライン制御装置１７は各ＨＴを識別しながら（ＨＴを識別する信号と共に）のパイプラインを制御している。すなわち、パイプライン制御装置１７は、制御対象のＨＴを常に特定している。
なお、パイプライン制御装置１７は、演算の種類やソースオペランド等を参照して、前の命令の実行結果を次の命令が必要とする場合には、次の命令のステージにアイドルステージを挿入するなどして、各ステージ間の整合性を確保する。また、例えば、あるプログラム（例えばプログラムＡ）にＩ／Ｏ待ちのようなハザードが生じた場合、パイプライン制御装置１７はスレッドスケジュール装置にそのプログラムＡを停止させ、別のプログラムＢを実行するよう要求する。

＜ソフトウェア監視装置１８＞
ソフトウェア監視装置１８は、プログラムＡ、Ｂの動作状況を監視して、動作状況をスケジュール制御装置１６に通知する。ソフトウェア監視装置１８の具体的な動作については実施例２以下で説明する。

スケジュール制御装置１６は、動作状況に応じて目標発行比率を、デフォルトのＱｏＳから、動作状況に応じたＱｏＳに切り替える。スケジュール制御装置１６は、例えばレジスタから各ＱｏＳを読み出せるようになっている。

本実施例では説明のため、次のようにＱｏＳが定められているとする。
・デフォルトのＱｏＳ
ＨＴ０：５０
ＨＴ１：５０
・第一のＱｏＳ
ＨＴ０：８０
ＨＴ１：２０
・第二のＱｏＳ
ＨＴ０：２０
ＨＴ１：８０
第一のＱｏＳは、ＨＴ０の目標発行比率がＨＴ１よりも高いので、プログラムＡのメインタスクＡとプログラムＢのアイドルタスクＢとが同時並行的に実行される動作状況のＱｏＳである。逆に、第二のＱｏＳは、プログラムＡのアイドルタスクＡとプログラムＢのメインタスクＢとが同時並行的に実行される動作状況のＱｏＳである。

ただし、スケジュール制御装置１６は、プログラムＡのメインタスクＡとプログラムＢのメインタスクＢが同時並行的に実行される動作状況では、デフォルトのＱｏＳを採用する。これにより、プログラムＡとＢのメインタスクＡ、Ｂに公平にＱｏＳを提供できる。また、プログラムＡのアイドルタスクＡとプログラムＢのアイドルタスクＢが同時並行的に実行される動作状況では、スケジュール制御装置１６は、動作状況が変わっても新たなＱｏＳを採用せず、直前のＱｏＳを採用したままとする。これにより、不要なＱｏＳの切り替えを防止し消費電力を抑制でき、また、オーバヘッドの発生も抑制できる。

なお、スケジュール制御装置１６は１クロック毎にＨＴ０，１を切り替えることができるので、上記ＱｏＳは一例に過ぎず、０：１００、１：９９、２：９８、３：９７、…、９９：１、１００：０、のようにより多段階のＱｏＳを採用できる。

また、ＨＴが３つ以上の場合、ソフトウェア監視装置１８は、３つのプログラムの動作状況をスケジュール制御装置１６に通知する。スケジュール制御装置１６は、個数分のＨＴに対応したＱｏＳを採用する（例えば、ＨＴが３つの場合、１０：２０：７０）。

図４は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。プログラムＡのメインタスクＡとアイドルタスクＡ、プログラムＢのメインタスクＡとアイドルタスクＢの組み合わせに応じて動作状況が定まる。スケジュール制御装置１６は、動作状況に応じてＱｏＳを切り替えていく。便宜的に、プログラムＡ、Ｂの動作状況を（ＨＴ０：ＨＴ１）の順番で表し、（メインＡ：メインＢ）を動作状況Ｉ、（メインＡ：アイドルＢ）を動作状況III、（アイドルＡ：メインＢ）を動作状況II、（アイドルＡ：アイドルＢ）を動作状況ＩV、と呼ぶことにする。図４の左から順番に説明する。

動作状況III：ＨＴ０はメインタスクＡを、ＨＴ１はアイドルタスクＢを、それぞれ実行している。したがって、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化Ｉ：イベントの発生や周期タスクのタイミングの到来等（以下、単にイベントの発生という）により、ＨＴ１が実行するタスクが、アイドルタスクＢからメインタスクＢに変化した。ソフトウェア監視装置１８は、この変化を検出して、プログラムの動作状況をスケジュール制御装置１６に通知する。

動作状況I：ＨＴ０はメインタスクＡを、ＨＴ１はメインタスクＢを、それぞれ実行している。したがって、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II：ＨＴ０において、メインタスクＡの実行が完了し、続いてアイドルタスクＡの実行が始まった。ソフトウェア監視装置１８は、この変化を検出して、プログラムの動作状況をスケジュール制御装置１６に通知する。

動作状況II：ＨＴ０はアイドルタスクＡを、ＨＴ１はメインタスクＢを、それぞれ実行している。したがって、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

タスク変化III：イベントの発生により、ＨＴ０が実行するタスクが、アイドルタスクＡからメインタスクＡに変化した。また、ほぼ同時期に、ＨＴ１において、メインタスクＢの実行が完了し、続いてアイドルタスクＢの実行が始まった。ソフトウェア監視装置１８は、この変化を検出して、プログラムの動作状況をスケジュール制御装置１６に通知する。

動作状況III：ＨＴ０はメインタスクＡを、ＨＴ１はアイドルタスクＢを、それぞれ実行している。したがって、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化IV：ＨＴ０において、メインタスクＡの実行が完了し、続いてアイドルタスクＡの実行が始まった。ソフトウェア監視装置１８は、この変化を検出するが、プログラムの動作状況をスケジュール制御装置１６に通知しない。

動作状況IV：ＨＴ０はアイドルタスクＡを、ＨＴ１はアイドルタスクＢを、それぞれ実行している。この場合、スケジュール制御装置１６は、ＱｏＳを切り替えないので、ＱｏＳは（８０：２０）のままである。

タスク変化V：イベントの発生により、ＨＴ１が実行するタスクが、アイドルタスクＢからメインタスクＢに変化した。ソフトウェア監視装置１８は、この変化を検出して、プログラムの動作状況をスケジュール制御装置１６に通知する。

動作状況II：ＨＴ０はアイドルタスクＡを、ＨＴ１はメインタスクＢを、それぞれ実行している。この場合、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

このように、マイクロプロセッサ１００は、プログラムＡ，Ｂの動作状況に応じてＨＴ０，１のＱｏＳを切り替えるので、ＥＣＵを機能統合して別のプログラムＡ，Ｂが、メインタスクとアイドルタスクを実行する動作状況でも、適切なＱｏＳにて各プログラムを実行することができる。

本実施例では、実施例１のソフトウェア監視装置１８の具体的な実現方法について説明する。
図５は、マイクロプロセッサ１００の概略構成図の一例を示す。図５のマイクロプロセッサ１００は、ソフトウェア監視装置１８がアドレス監視装置３３に置き換わった点で図２と異なる。なお、図５において図２と同一部には同一の符号を付しその説明は省略する。

アドレス監視装置３３の概略的な特徴部は次のようになる。
（１）アドレス監視装置３３は、プログラムＡのアイドルタスクＡの開始（終了）アドレス、アイドル属性タスクＡの開始（終了）アドレス、並びに、プログラムＢのアイドルタスクＢの開始（終了）アドレス及びアイドル属性タスクＢの開始（終了）アドレス、を読み出すことができる。
（２）アドレス監視装置３３は、ＨＴ０，１のＰＣの値を監視する。
（３）アドレス監視装置３３は、ＨＴ０，１のＰＣの値と、上記の各アドレスを比較して、動作状況を判定する。

ＰＣの値を、開始アドレスＡと終了アドレスＡと比較すれば、ＨＴ０がアイドルタスクＡを実行しているか否か（つまりメインタスクＡを実行していることか否かも）を判定できる。プログラムＢについても同様である。したがって、アドレス監視装置３３は、実施例１と同様に動作状況を判定することができる。

〔レジスタについて〕
本実施例のマイクロプロセッサ１００は、レジスタ群０，１とは別に複数のレジスタを有する。まず、アドレス監視装置３３には、アイドルタスク開始アドレスレジスタ１、アイドルタスク開始アドレスレジスタ２、アイドルタスク終了アドレスレジスタ１、及び、アイドルタスク終了アドレスレジスタ２、が接続されている。さらに、アドレス監視装置３３には、アイドル属性タスク開始アドレスレジスタ１、アイドル属性タスク開始アドレスレジスタ２、アイドル属性タスク終了アドレスレジスタ１、及び、アイドル属性タスク終了アドレスレジスタ２、が接続されている。

各レジスタに設定される値は以下のようになる。
アイドルタスク開始アドレスレジスタ１：アイドルタスクＡの開始アドレス
アイドルタスク開始アドレスレジスタ２：アイドルタスクＢの開始アドレス
アイドルタスク終了アドレスレジスタ１：アイドルタスクＡの終了アドレス
アイドルタスク終了アドレスレジスタ２：アイドルタスクＢの終了アドレス
アイドル属性タスク開始アドレスレジスタ１：アイドル属性タスクＡの開始アドレス
アイドル属性タスク開始アドレスレジスタ２：アイドル属性タスクＢの開始アドレス
アイドル属性タスク終了アドレスレジスタ１：アイドル属性タスクＡの終了アドレス
アイドル属性タスク終了アドレスレジスタ２：アイドル属性タスクＢの終了アドレス
図６は、これらのレジスタに設定される値をアドレスマップにて説明する図の一例である。マイクロプロセッサ１００がアクセスできるアドレス空間は定まっており、このアドレス空間の中に命令記憶部２３におけるプログラムＡ、プログラムＢのアドレス、データ記憶部２４におけるデータのアドレスも含まれる。

不揮発性の命令記憶部２３に記憶されたプログラムＡとプログラムＢのアドレスは固定であるので、アイドルタスクＡの開始アドレス、アイドルタスクＢの開始アドレス、アイドルタスクＡの終了アドレス、アイドルタスクＢの終了アドレスも固定である。したがって、ソフトウェア開発者がこれらのアドレスを特定しておけば、レジスタへの登録も可能となる。図６にはレジスタの値により示される各タスクのアドレスの範囲を示した。

ここで、アイドル属性タスクとは、アイドルタスクの処理をプリエンプトして（剥奪して）マイクロプロセッサ１００を使用した後、アイドルタスクに処理を返すタスクである。アイドル属性タスクは、例えば、アイドルタスクから呼び出されるライブラリを実体とする。アイドル属性タスクの開始アドレスと終了アドレスを登録するレジスタを備えたことで、アイドルタスクがアイドル属性タスクにプリエンプトされても、アイドルタスクの実行中かメインタスクの実行中かを判定可能となる。

しかしながら、アイドル属性タスクはライブラリであるため、メインタスクもアイドル属性タスクを使用することがある。すると、ＰＣがアイドル属性タスクＡの開始アドレス〜アイドル属性タスクＡの終了アドレスの範囲を示している場合、ＨＴ０がアイドルタスクＡを実行しているのかメインタスクＡを実行しているのか不明となる。そこで、後述するように、ＰＣが、アイドル属性タスクＡの開始アドレス〜アイドル属性タスクＡの終了アドレスの範囲を示している場合、アドレス監視装置３３は、アイドルタスクＡの開始アドレス〜アイドルタスクの終了アドレスからその範囲のアドレスに移行したか否により、アイドルタスクの実行中か否かを判定する。

また、スケジュール制御装置１６には、スケジュールレジスタ１、スケジュールレジスタ２、及び、デフォルトレジスタが接続されている。これらのレジスタに設定される値は以下のようになる。
スケジュールレジスタ１：第一のＱｏＳ
スケジュールレジスタ２：第二のＱｏＳ
デフォルトレジスタ ：デフォルトのＱｏＳ
図７は、スケジュールレジスタ１、スケジュールレジスタ２及びデフォルトレジスタに格納される値を模式的に示す図の一例である。図７（ａ）はスケジュールレジスタ１を示し、第一のＱｏＳが設定される。例えば上位16bitに「プログラムＡ実行割り当て設定エリア（８０）」が、下位16bitに「プログラムＢ実行割り当て設定エリア（２０）」が、それぞれ設定される。図７（ｂ）はスケジュールレジスタ２を示し、第二のＱｏＳが設定される。例えば上位16bitに「プログラムＡ実行割り当て設定エリア（２０）」が、下位16bitに「プログラムＢ実行割り当て設定エリア（８０）」が、それぞれ設定される。図７（ｃ）はデフォルトレジスタを示し、デフォルトのＱｏＳが設定される。例えば上位16bitに「プログラムＡ実行割り当て設定エリア（５０）」が、下位16bitに「プログラムＢ実行割り当て設定エリア（５０）」が、それぞれ設定される。

〔レジスタへの値の設定〕
これらのレジスタ３１とレジスタ３２は、例えばシステムレジスタである。システムレジスタは、マイクロプロセッサ１００が実行環境を制御するために使用したり、割り込み又は例外発生時にマイクロプロセッサ１００の状態を保持するレジスタである。汎用レジスタを使用してもよいが、システムレジスタを使用することでこれらのレジスタへの書き換え経路を限定でき、プログラムＡ、Ｂの実行中にレジスタの内容が書き換わることを防止できる。

システムレジスタの書き換えには、マイクロプロセッサ１００が用意するシステムレジスタ書き込み専用命令を利用する。そしてこのシステムレジスタ書き込み専用命令が記述されたソフトウェアが管理ソフト２０である。管理ソフト２０は、例えば、ＯＳのマイクロカーネル、ＢＩＯＳ、ブートローダ等、どのようなソフトウェアを実体としてもよい。

機能統合ＥＣＵ２００の電源がオンになると、マイクロプロセッサ１００が管理ソフト２０を自動実行する。管理ソフト２０は、自らに直接記述された、又は、データ記憶部２４に記憶されているテーブルを読み出し、アイドルタスクＡの開始アドレス、アイドルタスクＢの開始アドレス、アイドルタスクＡの終了アドレス、アイドルタスクＢの終了アドレス、アイドル属性タスクＡの開始アドレス、アイドル属性タスクＢの開始アドレス、アイドル属性タスクＡの終了アドレス、アイドル属性タスクＢの終了アドレス、第一のＱｏＳ、第二のＱｏＳ及びデフォルトのＱｏＳ、をレジスタ３１、３２に設定する。

このようにソフト的にアイドルタスクのアドレスを操作することで、機能統合ＥＣＵ２００の可用性・柔軟性が向上する。また、ハードウェアに負担を与えずにＱｏＳを切り替えることができる。

〔アドレス監視装置３３による動作状況の判定〕
レジスタ３１とレジスタ３２に値が設定されると、アドレス監視装置３３はプログラムＡ、Ｂの動作状況の判定を開始する。
図８は、アドレス監視装置３３の機能を模式的に示す図の一例である。アドレス監視装置３３は、アイドルタスク開始アドレスレジスタ１、アイドルタスク開始アドレスレジスタ２、アイドルタスク終了アドレスレジスタ１、アイドルタスク終了アドレスレジスタ２、アイドル属性タスク開始アドレスレジスタ１、アイドル属性タスク開始アドレスレジスタ２、アイドル属性タスク終了アドレスレジスタ１、及び、アイドル属性タスク終了アドレスレジスタ２、が入力側に接続された、比較器３４を有する。また、比較器３４の入力側には、命令バッファ０，１のＰＣがそれぞれ接続されている。比較器３４の出力側にはスケジュール制御装置１６が接続されている。

比較器３４は命令バッファ０から出力されたＰＣの値が変化したことを検出した場合、又は、１クロック毎に、ＰＣの値と、アイドルタスク開始アドレスレジスタ１、アイドルタスク終了アドレスレジスタ１、アイドル属性タスク開始アドレスレジスタ１、及び、アイドル属性タスク終了アドレスレジスタ１の値を比較する。

これにより、ＨＴ０がアイドルタスクＡの実行中であることが検出できる。アイドルタスクＡの実行中であることが検出できることは、アイドルタスクＡの実行が開始されたこと及び終了されたことも検出できる。なお、具体的には、アイドルタスクＡの実行中であることは、現在のＰＣの値が、
（ａ１）アイドルタスクＡ実行アドレス範囲に含まれること、
（ａ２）アイドルタスクＡ実行アドレス範囲から、プログラムＡライブラリアドレス範囲に含まれる状態になったこと、
のいずれかを満たす場合として検出される。

同様に、アドレス監視装置３３は、現在のＰＣの値が、
（ａ１‘）メインタスクＡ実行アドレス範囲に含まれること、
（ａ２‘）メインタスクＡ実行アドレス範囲から、プログラムＡライブラリアドレス範囲に含まれる状態になったこと、
のいずれかを満たす場合に、メインタスクＡの実行中であることを検出できる。しかしながら、本実施例ではアイドルタスクＡが実行されていなければメインタスクＡが実行されていること、及び、アイドルタスクＢが実行されていなければメインタスクＢが実行されていること、を判断できる。

よって、メインタスクＡ、Ｂが実行中か否かは積極的に判断しなくても、アイドルタスクの動作状況を監視することで、メインタスクＡ、Ｂの動作状況を監視した場合と同様になる。当然ながら、メインタスクＡ、Ｂが実行中か否かを判定しても、メインタスクＡ、Ｂの動作状況を監視できる。この監視方法は、エンジンが高回転時のエンジン制御など、メインタスクＡ、Ｂの負荷が高く、ある期間、アイドルタスクが１回も実行されない状況で有効である。

アドレス監視装置３３は、ＰＣの値が、アイドルタスクＡ実行アドレス範囲に一度でも含まれると、アイドルフラグＡを「１（オン）」に設定する。つまり、アドレス監視装置３３は、アイドルフラグＡが「１」になった後、ＰＣの値がアイドルタスクＡ実行アドレス範囲に含まれなくなっても、アイドルフラグＡを「０」にしない。

また、アドレス監視装置３３は、ＰＣの値が、アイドルタスクＡの終了アドレスに一致した場合にのみ、アイドルフラグＡを「０」にする。こうすることで、ＨＴ０がプログラムＡライブラリアドレス範囲の命令を実行しても、アイドルフラグＡが「０」になることを防止できる。

このようにして、アドレス監視装置３３は、ＨＴ０が、アイドルフラグＡが「１」の場合はアイドルタスクＡ(ライブラリを含む)を実行中であると、アイドルフラグＡが「０」の場合はメインタスクＡ(ライブラリを含む)を実行中であると、それぞれ判定できる。

同様に、ＨＴ１が、アイドルタスクＢの実行中であることは、現在のＰＣの値が、
（ｂ１）アイドルタスクＢ実行アドレス範囲に含まれること、
（ａ２）アイドルタスクＢ実行アドレス範囲から、プログラムＢライブラリアドレス範囲に含まれる状態になったこと、
のいずれかを満たす場合として検出される。

アドレス監視装置３３は、アイドルフラグＢの状態が「１」か「０」かによって、アイドルタスクＢ(ライブラリを含む)を実行中であること、又は、メインタスクＢ(ライブラリを含む)を実行中であること、をそれぞれ判定できる。

〔切り替え要求信号の出力〕
アドレス監視装置３３は、ＨＴ０がアイドルタスクＡを実行中か否か（メインタスクＡが実行中か否か）、及び、ＨＴ１がアイドルタスクＢを実行中か否か（メインタスクＢが実行中か否か）、に基づき、切り替え要求信号を出力する。切り替え要求信号は、スケジュール制御装置１６に、第一のＱｏＳ、第二のＱｏＳ又はデフォルトのＱｏＳのいずれかを指示する信号である。

図９は、プログラムＡ、Ｂの動作状況と、アドレス監視装置３３が出力する切り替え要求信号の関係の一例を示す図である。図９では、列方向にＨＴ０がメインタスクＡとアイドルタスクＡのどちらを実行中かの条件が、行方向にＨＴ１がメインタスクＢとアイドルタスクＢのどちらを実行中かの条件が、配置されている。したがって、図９では４つの動作状況に区分されている。

動作状況Iは、「ＨＴ０：メインタスクＡ ＨＴ１：メインタスクＢ」の動作状況なので、アドレス監視装置３３はデフォルトレジスタのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。

動作状況IIは、「ＨＴ０：アイドルタスクＡ ＨＴ１：メインタスクＢ」の動作状況なので、アドレス監視装置３３は第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。

動作状況IIIは、「ＨＴ０：メインタスクＡ ＨＴ１：アイドルタスクＢ」の動作状況なので、アドレス監視装置３３は第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。

動作状況IVは、「ＨＴ０：アイドルタスクＡ ＨＴ１：アイドルタスクＢ」の動作状況なので、アドレス監視装置３３は切り替え要求信号をスケジュール制御装置１６に出力しない。

アドレス監視装置３３は、動作状況が変化した場合にだけ、切り替え要求信号をスケジュール制御装置１６に出力する。これにより、消費電力を抑制できる。また、アドレス監視装置３３は、動作状況Ｉ〜IVに対応した切り替え要求信号を、継続的にスケジュール制御装置１６に出力してもよい。

〔ＱｏＳの切り替え〕
スケジュール制御装置１６は、切り替え要求信号をデコードして、切り替え要求信号に対応づけられたレジスタ３２からＱｏＳを読み出し、スケジュール制御装置１６に設定する。すなわち、切り替え要求信号に基づき、スケジュールレジスタ１、スケジュールレジスタ２又はデフォルトレジスタのいずれかから、それぞれ第一のＱｏＳ、第二のＱｏＳ又はデフォルトのＱｏＳを読み出す。こうすることで、マイクロプロセッサ１００は、プログラムＡ、Ｂの動作状況に応じたＱｏＳにてＨＴ０，１を切り替えることができる（ＨＴ０，１に実行権を与えることができる）。

〔プログラムの動作状況とＱｏＳの関係〕
図１０は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。図１０の動作状況は図４と同じである。なお、タスク変化の数値Ｉ〜Ｖと、動作状況の数値Ｉ〜ＩＶは特に関係していない。

タスク変化Ｉ： 動作状況III→I
アドレス監視装置３３は、動作状況がIに変化したことを検出して、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
アドレス監視装置３３は、動作状況がIIに変化したことを検出して、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

タスク変化III： 動作状況II→III
アドレス監視装置３３は、動作状況がIIIに変化したことを検出して、第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化IV： 動作状況III→IV
アドレス監視装置３３は、動作状況がIVに変化したことを検出する。この場合、アドレス監視装置３３は切り替え要求信号を出力しない。よって、ＱｏＳは（８０：２０）のままである。

タスク変化V： 動作状況IV→II
アドレス監視装置３３は、動作状況がIIに変化したことを検出して、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

以上説明したように、マイクロプロセッサ１００は、プログラムＡ，Ｂの動作状況に応じてＨＴ０，１のＱｏＳを切り替えるので、ＥＣＵを機能統合して別のプログラムＡ，Ｂが、メインタスクとアイドルタスクを実行する動作状況でも、適切なＱｏＳにて各プログラムを実行することができる。ソフト的にアイドルタスクのアドレスを操作することで、機能統合ＥＣＵ２００の可用性・柔軟性が向上し、コスト増を抑制できる。

既に述べたように、メインタスクは、イベント等が発生したことをトリガに実行され、アイドルタスクは、メインタスクが実行されていない場合にメインタスクの待ち状態を提供するタスクであることが多い。したがって、アイドルタスクの終了は、イベント発生と同じ意味である場合が多い。本実施例では、この事実を利用して、ＨＴ０，１がメインタスクの開始割り込みをトリガに、アイドルタスクの終了を検出し、動作状況の変化を検出するアドレス監視装置３３について説明する。このような態様は、種々の割り込みをトリガにメインタスクを開始する車両のＥＣＵに応用しやすいものとなる。

図１１は、マイクロプロセッサ１００の概略構成図の一例を示す。図１１のマイクロプロセッサ１００において、図５と同一部には同一の符号を付しその説明は省略する。本実施例のマイクロプロセッサ１００は割り込み判断装置３５を有し、割り込み判断装置３５がＩＮＴＣ（割り込みコントローラ）３６と接続されている。また、アドレス監視装置３３には、アイドルタスク開始アドレスレジスタ１、アイドルタスク開始アドレスレジスタ２、アイドル属性タスク開始アドレスレジスタ１、及び、アイドル属性タスク開始アドレスレジスタ２、が接続されている。すなわち、アイドルタスク終了アドレスレジスタ１、アイドルタスク終了アドレスレジスタ２、アイドル属性タスク終了アドレスレジスタ１、及び、アイドル属性タスク終了アドレスレジスタ２、を有する必要がない。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）アドレス監視装置３３は、プログラムＡのアイドルタスクＡの開始アドレス、アイドル属性タスクＡの開始アドレス、並びに、プログラムＢのアイドルタスクＢの開始アドレス及びアイドル属性タスクＢの開始アドレス、を読み出すことができる。
（２）アドレス監視装置３３は、ＨＴ０，１のＰＣの値を監視する。
（３）アドレス監視装置３３は、ＨＴ０，１のＰＣの値と、上記（１）の各アドレスを比較すると共に、割り込み判断装置３５からの割り込み判断結果を取得して、動作状況を判定する。

ＰＣの値を、アイドルタスクＡの開始アドレスと比較すれば、アドレス監視装置３３は、アイドルタスクＡが開始されたことを検出でき、メインタスクＡを開始する割り込み判断結果を取得すれば、アイドルタスクＡが終了されたこと（メインタスクＡが開始されたこと）を判定できる。プログラムＢについても同様である。

図１１の構成では、ソフトウェア開発者が、アイドルタスクＡの終了アドレス、アイドルタスクＢの終了アドレス、アイドル属性タスクＡの終了アドレス、及び、アイドル属性タスクＢの終了アドレス、を考慮しなくてよいので、レジスタの数も少なくて済み、開発コストを低減できる。

図１２は、アドレスマップを説明する図の一例である。図6と異なり、アイドルタスクＡの終了アドレス、アイドルタスクＢの終了アドレス、アイドル属性タスクＡの終了アドレス、及び、アイドル属性タスクＢの終了アドレスは、アドレス監視装置３３にとって不明となる。これを補うのがＩＮＴＣ３６と割り込み判断装置３５である。

〔ＩＮＴＣ３６、割り込み判断装置３５〕
ＩＮＴＣ３６は、周辺機器（タイマ、センサ、他のＥＣＵ等）、からの割り込み要因を受け付けて、マイクロプロセッサ１００に割り込み要求するＩＣである。ＩＮＴＣ３６と割り込み判断装置３５は、ＲＥＱ線５１、ＡＣＫ線５２及びＶＥＣ線５３を介して接続されている。ＲＥＱ線５１は、ＩＮＴＣ３６が割り込みの要求を通知する信号線である。割り込み判断装置３５は、既に割り込みの処理をしているなどの多重割り込みを調整して、割り込みを許可する場合にＡＣＫ線５２を介して通知する。ＩＮＴＣ３６はＶＥＣ線５３を介して、割り込み要因を通知する。

割り込み要因は、例えば、マイクロプロセッサ１００の異常発生、車両の他のＥＣＵからの異常発生、周期タイマの経過通知、特定のＩ／Ｏ（センサ）からの信号の通知、等である。ＩＮＴＣ３６は、ＶＥＣ線５３を介して、この割り込み要因に応じて定められている割り込みベクタ番号を割り込み判断装置３５に通知する。なお、ＩＮＴＣ３６は、プログラムＡとＢのいずれの割り込み要因も受け付ける。

割り込み判断装置３５は、割り込みベクタ番号に対応づけて割り込みハンドラの開始アドレスが登録された割込みベクターテーブルを有する。本実施例では、例えば割込みベクターテーブルに、その割り込みベクタ番号がプログラムＡのメインタスクＡを呼び出すものなのか、プログラムＢのメインタスクＢを呼び出すものなのか、が登録されている。割り込み判断装置３５は、ＩＮＴＣ３６から通知された割り込みベクタ番号に対応づけられた割り込みハンドラの開始アドレスをＰＣに設定する。これにより、割り込みハンドラが、アイドルタスクからメインタスクに切り替える処理を行い、ＨＴ０，１がメインタスクを開始することができる。

割り込み判断装置３５は、ＩＮＴＣ３６から割り込み要求を受け付けた場合、メインタスクＡ又はメインタスクＢを実行させるいずれかの割り込みが検出されたことを示す割り込み要求信号をアドレス監視装置３３に出力する。

〔アドレス監視装置３３による動作状況の判定〕
アドレス監視装置３３は、例えば、機能統合ＥＣＵ２００の電源がオンになるとプログラムＡ、Ｂの動作状況の判定を開始する。
図１３は、アドレス監視装置３３の機能を模式的に示す図の一例である。本実施例のアドレス監視装置３３の比較器３４には、アイドルタスク開始アドレスレジスタ１、アイドルタスク開始アドレスレジスタ２、アイドル属性タスク開始アドレスレジスタ１、及び、アイドル属性タスク開始アドレスレジスタ２、が入力側に接続されている。また、比較器３４の入力側には、命令バッファ０，１のＰＣがそれぞれ接続されている。また、比較器３４の入力側には割り込み判断装置３５が接続されている。比較器３４の出力側にはスケジュール制御装置１６が接続されている。

比較器３４は命令バッファ０から出力されたＰＣの値が変化したことを検出した場合、又は、１クロック毎に、ＰＣの値と、アイドルタスク開始アドレスレジスタ１の値を比較する。

これにより、ＨＴ０がアイドルタスクＡを実行中であることが検出できる。より正確には、アイドルタスクＡが開始したことを検出でき、終了していないことが間接的に（メインタスクＡの実行が開始されない）検出できる。なお、アイドルタスクＡの実行中であることは、ＰＣの値が、
（ａ１）アイドルタスクＡの開始アドレスと一致したこと、かつ、割り込み要求信号がメインタスクＡの実行の開始を要求しないこと
を満たす場合として検出される。

このように、本実施例のアドレス監視装置３３は、割り込み要求信号に基づきメインタスクＡの実行が開始されたこと（＝アイドルタスクＡの実行が終了したこと）を検出する。

具体的には、アドレス監視装置３３は、ＰＣの値が、アイドルタスクＡの開始アドレスに一致すると、アイドルフラグＡを「１（オン）」に設定する。アドレス監視装置３３は、アイドルフラグＡが「１」になった後、ＰＣの値がアイドルタスクＡの開始アドレスに一致しなくなっても、アイドルフラグＡを「０」にしない。

また、アドレス監視装置３３は、メインタスクＡの割り込みを要求する割り込み要求信号を検出した場合にのみ、ＰＣの値に関係なく、アイドルフラグＡを「０」にする。こうすることで、ＨＴ０がプログラムＡライブラリアドレス範囲の命令を実行しても、アイドルフラグＡが「０」になることを防止できる。

このようにして、アドレス監視装置３３は、アイドルフラグＡが「１」の場合、ＨＴ０がアイドルタスクＡ(ライブラリを含む)を実行中であると、アイドルフラグＡが「０」の場合、メインタスクＡ(ライブラリを含む)を実行中であると、それぞれ判定できる。

同様に、ＨＴ１が、アイドルタスクＢの実行中であることは、現在のＰＣの値が、
（ｂ１）アイドルタスクＢの開始アドレスと一致したこと、かつ、割り込み要求信号がメインタスクＢの実行の開始を要求しないこと
を満たす場合として検出される。

アドレス監視装置３３は、アイドルフラグＢの状態が「１」か「０」かによって、アイドルタスクＢ(ライブラリを含む)を実行中であること、又は、メインタスクＢ(ライブラリを含む)を実行中であること、をそれぞれ判定できる。

〔切り替え要求信号の出力〕
アドレス監視装置３３は、実施例２と同様に、切り替え要求信号を出力する。
図１４は、プログラムＡ、Ｂの動作状況と、アドレス監視装置３３が出力する切り替え要求信号の関係の一例を示す図である。図１４は図９と同じものである。本実施例は、プログラムＡ，Ｂの動作状況の判定方法が実施例２と異なり、動作状況と切り替え要求信号の関係は実施例２と同じである。

すなわち、動作状況Iでは、アドレス監視装置３３はデフォルトレジスタのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IIでは、アドレス監視装置３３は第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IIIでは、アドレス監視装置３３は第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IVでは、アドレス監視装置３３は切り替え要求信号をスケジュール制御装置１６に出力しない。

〔ＱｏＳの切り替え〕
スケジュール制御装置１６によるＱｏＳの切り替えは、実施例２と同様であるので説明を省略する。

〔プログラムの動作状況とＱｏＳの関係〕
図１５は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。図１５の動作状況は図4、図１０と同じであるが、ＱｏＳ入れ替えのトリガが異なる。

タスク変化Ｉ： 動作状況III→I
ＩＮＴＣ３６が、割り込み要因に基づく割り込みベクタ信号を割り込み判断装置３５に通知する。割り込み判断装置３５が割り込みベクタ信号からメインタスクＢを開始させる割り込み要求を受け付け、割り込み要求信号をアドレス監視装置３３に通知する。アドレス監視装置３３は、動作状況がIに変化したことを検出して、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
アドレス監視装置３３は、ＰＣの値がアイドルタスクＡの開始アドレスと一致したことから、動作状況がIIに変化したことを検出して、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

タスク変化III： 動作状況II→III
ＩＮＴＣ３６が、割り込み要因に基づく割り込みベクタ信号を割り込み判断装置３５に通知する。割り込み判断装置３５が割り込みベクタ信号からメインタスクＡを開始させる割り込み要求を受け付け、割り込み要求信号をアドレス監視装置３３に通知する。また、アドレス監視装置３３は、ＰＣの値がアイドルタスクＢの開始アドレスと一致したことを検出する。これらからアドレス監視装置３３は、動作状況がIIIに変化したことを検出して、第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化IV： 動作状況III→IV
アドレス監視装置３３は、ＰＣの値がアイドルタスクＡの開始アドレスと一致したことから、動作状況がIVに変化したことを検出する。この場合、アドレス監視装置３３は切り替え要求信号を出力しない。よって、ＱｏＳは（８０：２０）のままである。

タスク変化V： 動作状況IV→II
ＩＮＴＣ３６が、割り込み要因に基づく割り込みベクタ信号を割り込み判断装置３５に通知する。割り込み判断装置３５が割り込みベクタ信号からメインタスクＢを開始させる割り込み要求を受け付け、割り込み要求信号をアドレス監視装置３３に通知する。アドレス監視装置３３は、動作状況がIIに変化したことを検出して、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

以上説明したように、マイクロプロセッサ１００は、実施例２の効果に加え、車両のＥＣＵに応用しやすい態様で、ＱｏＳを切り替えることができる。割り込み判断装置３５やＩＮＴＣ３６は一般的なＥＣＵに設けられているので、レジスタの数が減っただけ実施例２よりもコスト減とすることができる。

これまでの実施例ではプログラムがＯＳを含むか否かを限定しなかったが、本実施例ではＯＳの機能を利用してＱｏＳを切り替えるマイクロプロセッサ１００について説明する。元々、ＯＳが備える機能（Ｈｏｏｋ機能）とその機能をトリガにした処理（Ｈｏｏｋ処理）によりＱｏＳを切り替えることで、レジスタ３１の数を含めハードウェアリソースに影響されることなく、ＱｏＳ比率の変更が可能になる。また、ソフトウェア開発時の自由度も増す。

図１６は、マイクロプロセッサ１００の概略構成図の一例を示す。図１６において図２と同一部には同一の符号を付しその説明は省略する。図１６のプログラムＡ、Ｂは、共通のＯＳ３７上で実行される。また、マイクロプロセッサ１００は、ソフトウェア監視装置１８としてＨｏｏｋ監視装置３８を有する。また、Ｈｏｏｋ監視装置３８にはスケジュール切り替えレジスタ３９が設けられている。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）ＯＳ３７のスケジューラがメインタスクＡ、アイドルタスクＡ、メインタスクＢ及びアイドルタスクＢの状態を管理する。
（２）ＯＳ３７のスケジューラが、アイドルタスクＡ、Ｂの実行を監視し、PreTaskHook及びPostTaskHookを利用してＨｏｏｋ処理を起動する。
（３）Ｈｏｏｋ処理がスケジュール切り替えレジスタ３９を操作する。

〔Ｈｏｏｋ処理〕
図１６に示したようにプログラムＡ、ＢはそれぞれＯＳ３７上で実行される。ＯＳ３７はプログラムＡ，Ｂに共通である必要はなく、ＨＴ０がプログラムＡに専用のＯＳ_Ａを実行し、ＨＴ１がプログラムＢに専用のＯＳ_Ｂを、それぞれ実行してもよい。

ＯＳ３７は、マルチタスクに対応したリアルタイムＯＳ（タスクの最長実行時間が保証されている）であることが好ましい。ＯＳ３７の一例としては、μＩＴＲＯＮ、Ｔｏｐｐｅｒｓ／ＯＳＥＫ（Open system together with interfaces for automotive electronics）等が挙げられる。

図１７は、ＯＳ３７が提供するＨｏｏｋ処理を模式的に説明する図の一例である。機能統合ＥＣＵ２００の起動時に、スケジューラにはメインタスクとアイドルタスクが登録される。各タスクは、例えば、実行状態、実行可能状態、及び、待ち状態の３つの状態を取り得るが、スケジューラは、ＨＴ０、１にそれぞれ割り当てるタスクをスケジューリングする。実行状態は、ＨＴ０、１がそのタスクを実行している状態を、実行可能状態は、タスクの実行に必要な条件は整っているが、当該タスクよりも優先順位が高いタスクが実行状態であるため、ＨＴ０、１が開放されるのを待っている状態である。実行待ち状態は、タスクを実行するための条件、例えば、周期サイクルの経過やイベント（主に割り込みの発生）を待っている状態である。

スケジューラとディスパッチャは、例えば次のような手順で状態間を遷移させる。
ａ）実行可能状態のタスクがアイドルタスクだけであれば、ディスパッチャがアイドルタスクをＨＴ０（１）にディスパッチする。
ｂ）割り込みなどによりメインタスクが実行可能状態になると、スケジューラがアイドルタスクを実行可能状態にする。
ｃ）メインタスクの方が優先であることから、ディスパッチャがメインタスクをＨＴ０（１）にディスパッチする。
ｄ）メインタスクの実行が完了すると、メインタスクは消滅する。
ｅ）ディスパッチャが、アイドルタスクをＨＴ０（１）にディスパッチする。

図１７において、アイドルタスクが実行された状態から説明する。アイドルタスクが継続的に実行されるため、アイドルタスクは常に実行状態である。何らかの割り込みが発生すると、アイドルタスクが終了して（中断して）実行可能状態になるが、スケジューラはこの遷移をフックして、メインタスクに実行権を与える。

メインタスクとアイドルタスクが実行可能状態になるので、ディスパッチャはメインタスクを実行状態にする。ディスパッチの直後、PreTaskHookが起こり、ＨＴ０，１はHook処理Ｐｒを実行する。

メインタスクの実行を完了すると、スケジューラは実行状態のタスクが消滅したことを検出する。すでに、アイドルタスクが実行可能状態なので、スケジューラはアイドルタスクに実行権を与える。アイドルタスクが実行可能状態になるので、ディスパッチャはアイドルタスクを実行状態にする。ディスパッチの直後、PostTaskHookが起こり、ＨＴ０，１はHook処理Ｐｔを実行する。

このように、メインタスクの処理開始の直後にPreTaskHookによるＨｏｏｋ処理Ｐｒが、メインタスクの処理終了の直後にPostTaskHookによるＨｏｏｋ処理Ｐｔが、それぞれ実行される。

〔Ｈｏｏｋ処理〕
Ｈｏｏｋ処理Ｐｒは、PreTaskHookが呼び出すＨｏｏｋ処理であり、Ｈｏｏｋ処理ＰｔはPostTaskHookが呼び出すＨｏｏｋ処理である。しかしながら、いずれのＨｏｏｋ処理もスケジュール切り替えレジスタ３９に値を書き込む処理である。

スケジュール切り替えレジスタ３９は、第一のＱｏＳ、第二のＱｏＳ、又は、デフォルトのＱｏＳのいずれかを指示する情報が書き込まれる、レジスタである。スケジュール切り替えレジスタ３９が、ＨＴ０，１に共通であれば、Ｈｏｏｋ監視装置３８は、例えばスケジュール切り替えレジスタ３９の上位16bitにプログラムＡの「アイドルタスクＡの開始を示す情報」又は「アイドルタスクＡの終了を示す情報」を書き込む。同様に、Ｈｏｏｋ監視装置３８は、例えばスケジュール切り替えレジスタ３９の下位16bitにプログラムＢの「アイドルタスクＢの開始を示す情報」又は「アイドルタスクＢの終了を示す情報」を書き込む。

また、スケジュール切り替えレジスタ３９が、ＨＴ０，１に別々に用意されていてもよい。この場合は、Ｈｏｏｋ監視装置３８が、プログラムＡ、Ｂそれぞれのスケジュール切り替えレジスタ３９に、「アイドルタスクＡ（Ｂ）の開始を示す情報」又は「アイドルタスクＡ（Ｂ）の終了を示す情報」を書き込む。

なお、スケジュール切り替えレジスタ３９に値を書き込む方法は以下の２つの方法が例としてあげられる。
(i) システムレジスタアクセス専用命令を使う。

スケジュール切り替えレジスタ３９がシステムレジスタとして定義されている場合に有効である。システムレジスタに書き込むための命令は、ＯＳ３７の特権モードで使用が許可されるシステムレジスタアクセス専用なので、誤ってスケジュール切り替えレジスタ３９に値が書き込まれることがない。
(ii) スケジュール切り替えレジスタ３９切り替え（書き換え）専用命令を使う。

スケジュール切り替えレジスタ３９がＩ／Ｏレジスタとして定義されている場合に有効である。スケジュール切り替えレジスタ３９には、専用の命令が用意される。この命令はＯＳ３７のユーザモードでのみ使用できる命令である。

(i)と(ii)を使い分けることで、セキュリティ性が向上するという効果が得られる。

〔Ｈｏｏｋ監視装置３８〕
図１８は、Ｈｏｏｋ監視装置３８の概略構成図の一例を示す。スケジュール切り替えレジスタ３９がプログラムＡ,Ｂに共通の場合、0x00000000、0x00000001、0x00010000、又は、0x00010001、がスケジュール切り替えレジスタ３９に設定される。Ｈｏｏｋ監視装置３８は、この値をそのままスケジュール制御装置１６に出力する。この値が本実施例の切り替え要求信号である。

例えば、0x00000000がアイドルタスクＡの終了とアイドルタスクＢの終了を（＝ＨＴ０がメインタスクＡを、ＨＴ１がメインタスクＢを実行中）、0x00000001がアイドルタスクＡの終了とアイドルタスクＢの開始を（＝ＨＴ０がメインタスクＡを、ＨＴ１がアイドルタスクＢを実行中）、0x00010001がアイドルタスクＡの開始とアイドルタスクＢの開始を（＝ＨＴ０がアイドルタスクＡを、ＨＴ１がアイドルタスクＢを実行中）、0x00010000がアイドルタスクＡの開始とアイドルタスクＢの終了を（＝ＨＴ０がアイドルタスクＡを、ＨＴ１がメインタスクＢを実行中）、を意味する。

〔ＱｏＳの切り替え〕
スケジュール制御装置１６による、切り替え要求信号をデコードしてＨＴ０とＨＴ１のＱｏＳの切り替える。
すなわち、スケジュール制御装置１６は、次のように、スケジュール切り替えレジスタ１，２又はデフォルトレジスタから、ＱｏＳを読み出しＨＴ０とＨＴ１のＱｏＳを切り替える。
・切り替え要求信号＝0x00000000
ＨＴ０：ＨＴ１＝（５０：５０）
・切り替え要求信号＝0x00000001
ＨＴ０：ＨＴ１＝（８０：２０）
・切り替え要求信号＝0x00010001
直前のＱｏＳを維持。または、Ｈｏｏｋ監視装置３８が切り替え要求信号を出力しないようにしてもよい。
・切り替え要求信号＝0x00010000
ＨＴ０：ＨＴ１＝（２０：８０）
〔プログラムの動作状況とＱｏＳの関係〕
図１９は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。図１９の動作状況は図４、図１０、図１５と同じであるが、ＱｏＳ入れ替えのトリガが異なる。

タスク変化Ｉ： 動作状況III→I
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。これにより、ＯＳ３７がPreTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
メインタスクＡの実行が完了すると、ＯＳ（ディスパッチャ）がアイドルタスクＡをディスパッチする前に、ＯＳ３７がPostTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

タスク変化III： 動作状況II→III
メインタスクＡの実行が開始することでアイドルタスクＡの実行が終了される。これにより、ＯＳ３７がPrTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。

また、ほぼ同時期に、メインタスクＢの実行が完了し、ＯＳ（ディスパッチャ）がアイドルタスクＢをディスパッチする前に、ＯＳ３７がPostTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。

Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化IV： 動作状況III→IV
メインタスクＡの実行が完了すると、ＯＳ（ディスパッチャ）がアイドルタスクＡをディスパッチする前に、ＯＳ３７がPostTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。この場合、動作状況がIVなので、Ｈｏｏｋ監視装置３８が切り替え要求信号を出力しても、スケジュール制御し装置はＱｏＳを切り替えないか、又は、Ｈｏｏｋ監視装置３８が切り替え要求信号を出力しない。よって、ＱｏＳは（８０：２０）のままである。

タスク変化V： 動作状況IV→II
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。これにより、ＯＳ３７がPreTaskHookを実行し、スケジュール切り替えレジスタ３９に値を書き込む。Ｈｏｏｋ監視装置３８は、切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

以上説明したように、マイクロプロセッサ１００は、ＯＳ３７の機能を利用してＱｏＳを切り替えることができるので、多くのレジスタを用意する実施例２，３と比べてコスト減とすることができる。

実施例４では、ＯＳ３７のＨｏｏｋ機能を利用したが、本実施例ではＯＳ３７が管理するタスクＩＤを利用してＱｏＳを切り替えるマイクロプロセッサ１００について説明する。タスクＩＤを利用することで、Ｈｏｏｋ処理を多用する必要がなくなり、ソフトウェア開発時の自由度が増大する。

図２０は、マイクロプロセッサ１００の概略構成図の一例を示す。図２０において図１６と同一部には同一の符号を付しその説明は省略する。図２０のマイクロプロセッサ１００は、ソフトウェア監視装置１８としてＴａｓｋＩＤ監視装置４１を有する。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）ＯＳ３７のスケジューラがメインタスクＡ、アイドルタスクＡ、メインタスクＢ及びアイドルタスクＢの状態を管理して、現在実行中のタスクのタスクＩＤをカレントＴａｓｋＩＤレジスタ１，２に設定する。
（２）ＯＳ３７等の管理ソフト２０が、アイドルタスクＡ、ＢのタスクＩＤをアイドルＴａｓｋＩＤレジスタ１，２に設定する。
（３）ＴａｓｋＩＤ監視装置４１が、カレントＴａｓｋＩＤレジスタ１，２とアイドルＴａｓｋＩＤレジスタ１，２に設定された値を比較して、切り替え要求信号を出力する。

〔タスクＩＤ〕
実施例４にて説明したように、ＯＳ３７は各タスクをスケジューリングしたりディスパッチしたりするため、タスクを管理している。このため、ＯＳ３７は各タスクにユニークなタスクＩＤを割り当て、タスクＩＤで各タスクを識別する。したがって、例えば、ＯＳ３７のスケジューラにとって、ＨＴ０，１のそれぞれで実行状態にある（カレントの）タスクのタスクＩＤは既知である。したがって、カレントのタスクのタスクＩＤを、アイドルタスクのタスクＩＤと比較すれば、ＨＴ０，１のそれぞれがアイドルタスクＡ、Ｂを実行しているか否か、すなわち動作状況が明らかになる。

管理ソフト２０は、例えば、機能統合ＥＣＵ２００の起動時に、アイドルＴａｓｋＩＤレジスタ１にアイドルタスクＡのタスクＩＤを、アイドルＴａｓｋＩＤレジスタ２にアイドルタスクＢのタスクＩＤを、それぞれ設定する。

また、例えば、スケジューラは、ＨＴ０のタスクが切り替わると、カレントＴａｓｋＩＤレジスタ１に実行状態のタスクのタスクＩＤを設定し、ＨＴ１のタスクが切り替わると、カレントＴａｓｋＩＤレジスタ２に実行状態のタスクのタスクＩＤを設定する。

よって、アイドルＴａｓｋＩＤレジスタ１の値とカレントＴａｓｋＩＤレジスタ１の値の比較結果、及び、アイドルＴａｓｋＩＤレジスタ２の値とカレントＴａｓｋＩＤレジスタ２の値の比較結果から、ＴａｓｋＩＤ監視装置４１はプログラムＡ、Ｂの動作状況を特定できる。

〔ＴａｓｋＩＤ監視装置４１による動作状況の判定〕
ＴａｓｋＩＤ監視装置４１は、例えば、機能統合ＥＣＵ２００の電源がオンになるとプログラムＡ、Ｂの動作状況の判定を開始する。
図２１は、ＴａｓｋＩＤ監視装置４１の機能を模式的に示す図の一例である。ＴａｓｋＩＤ監視装置４１の比較器３４には、アイドルＴａｓｋＩＤレジスタ１、カレントＴａｓｋＩＤレジスタ１、アイドルＴａｓｋＩＤレジスタ２、及び、カレントＴａｓｋＩＤレジスタ２が接続されている。本実施例ではＰＣの接続は不要である。

比較器３４は、アイドルＴａｓｋＩＤレジスタ１、カレントＴａｓｋＩＤレジスタ１、アイドルＴａｓｋＩＤレジスタ２、又は、カレントＴａｓｋＩＤレジスタ２の設定値が変化したことを検出した場合、又は、１クロック毎に、アイドルＴａｓｋＩＤレジスタ１の値とカレントＴａｓｋＩＤレジスタ１の値を比較し、又は、アイドルＴａｓｋＩＤレジスタ２の値とカレントＴａｓｋＩＤレジスタ２の値を比較する。

アイドルＴａｓｋＩＤレジスタ１の値とカレントＴａｓｋＩＤレジスタ１の値が一致すれば、ＨＴ０はアイドルタスクＡを実行していることになる。一致しなければ、ＨＴ０はメインタスクＡを実行していることになる。アイドルＴａｓｋＩＤレジスタ２の値とカレントＴａｓｋＩＤレジスタ２の値が一致すれば、ＨＴ１はアイドルタスクＢを実行していることになる。一致しなければ、ＨＴ１はメインタスクＢを実行していることになる。

〔切り替え要求信号の出力〕
ＴａｓｋＩＤ監視装置４１は、プログラムＡ、Ｂの動作状況に応じて切り替え要求信号を出力する。
図２２は、プログラムＡ、Ｂの動作状況と、ＴａｓｋＩＤ監視装置４１が出力する切り替え要求信号の関係の一例を示す図である。図２２は、図１４、図９と同じものである。すなわち、動作状況と切り替え要求信号の関係は実施例２と同じである。

これまでと同様、動作状況Iでは、ＴａｓｋＩＤ監視装置４１はデフォルトレジスタのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IIでは、ＴａｓｋＩＤ監視装置４１は第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IIIでは、ＴａｓｋＩＤ監視装置４１は第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IVでは、ＴａｓｋＩＤ監視装置４１は切り替え要求信号をスケジュール制御装置１６に出力しない。

〔プログラムの動作状況とＱｏＳの関係〕
図２３は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。図２３の動作状況は図４、図１０、図１５、図１９と同じであるが、ＱｏＳ入れ替えのトリガが異なる。既に、管理ソフト２０は、アイドルＴａｓｋＩＤレジスタ１にアイドルタスクＡのタスクＩＤを、アイドルＴａｓｋＩＤレジスタ２にアイドルタスクＢのタスクＩＤを、設定している。

タスク変化Ｉ： 動作状況III→I
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＢのタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。カレントＴａｓｋＩＤレジスタ２の値とアイドルＴａｓｋＩＤレジスタ２の値は一致しない。また、ＨＴ０はメインタスクＡを実行しているので、動作状況はＩになる。よって、ＴａｓｋＩＤ監視装置４１は、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
メインタスクＡの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＡのタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。したがって、アイドルＴａｓｋＩＤレジスタ１のタスクＩＤとカレントＴａｓｋＩＤレジスタ１のタスクＩＤが一致する。また、ＨＴ１はメインタスクＢを実行しているので、動作状況はIIになる。よって、ＴａｓｋＩＤ監視装置４１は、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

タスク変化III： 動作状況II→III
メインタスクＡの実行が開始されることでアイドルタスクＡの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＡのタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ１の値は一致しない。また、メインタスクＢの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＢのタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。したがって、アイドルＴａｓｋＩＤレジスタ２のタスクＩＤとカレントＴａｓｋＩＤレジスタ２のタスクＩＤが一致する。よって、動作状況はIIIになる。ＴａｓｋＩＤ監視装置４１は、第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（８０：２０）に設定する。

タスク変化IV： 動作状況III→IV
メインタスクＡの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＡのタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。したがって、アイドルＴａｓｋＩＤレジスタ１のタスクＩＤとカレントＴａｓｋＩＤレジスタ１のタスクＩＤが一致する。また、ＨＴ１はアイドルタスクＢを実行しているので、動作状況はIVになる。よって、ＴａｓｋＩＤ監視装置４１は、切り替え要求信号をスケジュール制御装置１６に出力しない。よって、ＱｏＳは（８０：２０）のままである。

タスク変化V： 動作状況IV→II
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＢのタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。カレントＴａｓｋＩＤレジスタ２の値とアイドルＴａｓｋＩＤレジスタ２の値は一致しない。また、ＨＴ０はアイドルタスクＡを実行しているので、動作状況はIIになる。よって、ＴａｓｋＩＤ監視装置４１は、第二のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（２０：８０）に設定する。

以上説明したように、マイクロプロセッサ１００は、ＯＳ３７の機能を利用してＱｏＳを切り替えることができるので、多くのレジスタを用意する実施例４と比べてコスト減とすることができる。

本実施例では、ＱｏＳをより多段階に切り替えるマルチプロセッサについて説明する。
図２４は、マイクロプロセッサ１００の概略構成図の一例を示す。図２４において、図５と同一部には同一の符号を付しその説明は省略する。図２４のマイクロプロセッサ１００は、パイプライン制御装置１７がアドレス監視装置３３にＨＴ０，１の負荷比を通知する点で、これまでの実施例と異なる。また、スケジュール制御装置１６に、スケジュールレジスタ１，２，３、４及びデフォルトレジスタが接続されている。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）パイプライン制御装置が、ＨＴ０，１の負荷比をアドレス監視装置３３に通知する。
（２）管理ソフト２０がスケジュールレジスタ１，２，３、４及びデフォルトレジスタにそれぞれ異なる５つのＱｏＳを設定する。
（３）スケジュール制御装置１６は、プログラムＡ、Ｂの動作状況と負荷比に基づき、ＨＴ０、１を５段階のＱｏＳに切り替える。

ＨＴ０がメインタスクＡを、ＨＴ１がアイドルタスクＢを実行している場合、又は、ＨＴ０がアイドルタスクＡを、ＨＴ１がメインタスクＢを実行している場合、アドレス監視装置３３は負荷比に応じて適切なＱｏＳをスケジュール制御装置１６に指示することができる。

〔プログラムＡ、Ｂの動作状況〕
本実施例では、実施例２と同様に、アドレス監視装置３３は、現在のＰＣの値が、
（ａ１）アイドルタスクＡ実行アドレス範囲に含まれること、
（ａ２）アイドルタスクＡ実行アドレス範囲から、プログラムＡライブラリアドレス範囲に含まれる状態になったこと、
のいずれかを満たす場合に、ＨＴ０がアイドルタスク０を実行中であると判定する。プログラムＢについても同様である。

なお、プログラム動作状況は、実施例３のようにアドレス監視装置３３と割り込み判断装置３５により、実施例４のようにＨｏｏｋ監視装置３８により、又は、実施例５のようにＴａｓｋＩＤ監視装置４１により、検出してもよい。

〔ＨＴ０，１の負荷比〕
パイプライン制御装置１７は、上記のようにステージを制御しているＨＴ０，１を特定している。したがって、パイプライン制御装置１７にとって、ＨＴ０，１の実際の実行比率である負荷比は既知である。負荷比は、例えば、単位時間におけるＨＴ０の命令の発行数とＨＴ１の命令の発行数の比、又は、単位時間におけるＨＴ０の命令の完了数とＨＴ１の命令の完了数の比、である。ここでは、例えば、後者の指標を採用し、所定クロック数（時間）の命令の完了数から負荷比を求めるものとする。なお、負荷比は、一の位を丸め１０％単位にする。

上記のように、スケジュール制御装置１６はフィードバック制御していないので、ＱｏＳと実際の負荷比は完全には一致しない。そこで、アドレス監視装置３３は、動作状況毎に負荷比を記録しておき、動作状況と負荷比に応じて切り替え要求信号をスケジュール制御装置１６に出力する。

図２５は、アドレス監視装置３３が記録した動作状況毎の負荷比の一例を模式的に示す図の一例である。アドレス監視装置３３は、各動作状況毎に最も新しい負荷比を記憶している。ここで、動作状況IVの負荷比の合計が１００でないのでは、ＨＴ０，１がＮＯＰを実行するなど、両者ともライトバックに至る命令をほとんど実行しなかったためである。

〔レジスタについて〕
レジスタ３１は、実施例２と同じものである。また、レジスタ３１の値の設定方法も実施例２と同じである。

これに対し、スケジュール制御装置１６には、スケジュールレジスタ１〜４、及び、デフォルトレジスタが接続されている。これらのレジスタに設定される値は以下のようになる。
スケジュールレジスタ１：第一の１のＱｏＳ
スケジュールレジスタ２：第一の２のＱｏＳ
スケジュールレジスタ３：第二の１のＱｏＳ
スケジュールレジスタ４：第二の２のＱｏＳ
デフォルトレジスタ ：デフォルトのＱｏＳ
第一の１のＱｏＳと第一の２のＱｏＳは、ＨＴ０がメインタスクＡをかつＨＴ１がアイドルタスクＢを、それぞれ実行している場合に設定されるＱｏＳである。同様に、第二の１のＱｏＳと第二の２のＱｏＳは、ＨＴ１がメインタスクＢをかつＨＴ０がアイドルタスクＡを、それぞれ実行している場合に設定されるＱｏＳである。

ＱｏＳのフォーマットは実施例２と同様である。すなわち、上位１６bitが「プログラムＡ実行割り当て設定エリア」で、下位16bitが「プログラムＢ実行割り当て設定エリア」である。

なお、アドレス監視装置３３が有するスケジュール切り替えレジスタ３９については後述する。

レジスタに値を設定するのは、実施例２と同様に管理ソフト２０とすることができる。本実施例では管理ソフト２０の一例として、ＯＳ３７が値を設定するものとする。

図２６は、ＯＳ３７によるスケジュールレジスタ１〜４への値の設定を模式的に説明する図の一例である。ＯＳ３７等の管理ソフト２０は、マイクロプロセッサ１００のＲＡＭ又はＲＯＭにスケジュール管理テーブル４２を記憶している。本実施例では、このスケジュール管理テーブル４２に、スケジュールレジスタ１〜４に設定すべき値が登録されている。

図２６の左に示すように、スケジュール管理テーブル４２には第一の１のＱｏＳ＝（９０：１０）、第一の２のＱｏＳ＝（６０：４０）、第二の１のＱｏＳ＝（４０：６０）、第二の２のＱｏＳ＝（1０：９０）の４つのＱｏＳが登録されている。

そして、例えば、機能統合ＥＣＵ２００の電源がオンになると、マイクロプロセッサ１００がＯＳ（管理ソフト２０）３７を自動実行する。ＯＳ３７は、スケジュール管理テーブル４２を読み出し、スケジュールレジスタ１〜４に、それぞれのＱｏＳを設定する。

〔切り替え要求信号の出力〕
図２７を用いて本実施例の切り替え要求信号について説明する。図２７の比較器３４以下の構成は図８と同じものである。したがって、比較器３４は、動作状況を識別する信号を出力することができる。比較器３４は、動作状況がI〜IIIの場合は、スケジュール切り替えレジスタ３９の上位16bitに「１」を設定する。動作状況がIVの場合は、ＱｏＳを切り替えないので、スケジュール切り替えレジスタ３９の上位16bitに「０」を設定する。上位16bit（スケジュール切り替えトリガ）が「１」の場合、下位16bitのスケジュール指示値の値がスケジュール制御装置１６に送信される。

動作状況を識別する信号は、図２５に示した動作状況毎の負荷比を選択する信号となり、例えば、動作状況IIの場合はメインタスクＡの負荷比として「９０」を選択し、動作状況IIIの場合はメインタスクＢの負荷比として「９０」を選択する。

選択された負荷比は第２比較器４３に出力され、定数と比較される。この定数の値もレジスタ３１と同様に設定される。図では、第２比較器４３は、メインタスクＡの実際の負荷比「９０」と定数（８０）を比較し、負荷比の方が大きい場合は「１」を、負荷比が定数以下の場合は「２」を、スケジュール切り替えレジスタ３９の下位１６bitに設定する。同様に、第２比較器４３は、メインタスクＢの実際の負荷比「９０」と定数（８０）を比較し、負荷比の方が大きい場合は「４」を、負荷比が定数以下の場合は「３」を、スケジュール切り替えレジスタ３９の下位１６bitに設定する。

スケジュール切り替えレジスタ３９の下位16bitのスケジュール指示値は、スケジュールレジスタ１〜４のいずれかを選択するスケジュール指示の信号となる。したがって、アドレス監視装置３３は、負荷比に応じて、適切なＱｏＳに切り替える切り替え要求信号をスケジュール制御装置１６に出力することができる。

なお、動作状況がＩの場合、比較器３４がスケジュール切り替えレジスタ３９の下位１６bitにデフォルトレジスタを指示する値（例えば「５」）を設定することで、アドレス監視装置３３は、デフォルトのＱｏＳをスケジュール制御装置１６に出力することができる。動作状況がＩの場合も、第２比較器４３を介して、ＱｏＳを多段階に指定するようにしてもよい。

〔プログラムの動作状況とＱｏＳの関係〕
図２８は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。図２８の動作状況は図４、図１０、図１５、図１９、図２３と同じであるが、各動作状況に負荷比が記されている。この負荷比は、対応する動作状況の負荷比である。

タスク変化Ｉ： 動作状況III→I
アドレス監視装置３３は、動作状況がIに変化したことを検出して、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
アドレス監視装置３３は、動作状況がIIに変化したことを検出する。これにより、第２比較器４３が過去の不図示の動作状況IIの負荷比と定数を比較して、スケジュールレジスタ４を指示するスケジュール指示値をスケジュール切り替えレジスタ３９の下位１６bitに設定する。これにより、スケジュール制御装置１６は、スケジュールレジスタ４から読み出した（１０：９０）のＱｏＳを設定する。

タスク変化III： 動作状況II→III
アドレス監視装置３３は、動作状況がIIIに変化したことを検出する。これにより、第２比較器４３が最後の動作状態IIIの負荷比（９０：１０）と定数を比較して、スケジュールレジスタ１を指示するスケジュール指示値をスケジュール切り替えレジスタ３９の下位１６bitに設定する。これにより、スケジュール制御装置１６は、スケジュールレジスタ１から読み出した（９０：１０）のＱｏＳを設定する。

タスク変化IV： 動作状況III→IV
アドレス監視装置３３は、動作状況がIVに変化したことを検出する。この場合、アドレス監視装置３３は切り替え要求信号を出力しない。よって、ＱｏＳは（９０：１０）のままである。

タスク変化V： 動作状況IV→II
アドレス監視装置３３は、動作状況がIIに変化したことを検出する。これにより、第２比較器４３が最後の動作状態IIの負荷比（１０：９０）と定数を比較して、スケジュールレジスタ４を指示するスケジュール指示値をスケジュール切り替えレジスタ３９の下位１６bitに設定する。これにより、スケジュール制御装置１６は、スケジュールレジスタ４から読み出した（１０：９０）のＱｏＳを設定する。

以上説明したように、本実施例のマイクロプロセッサ１００は、プログラムＡ、Ｂの同じ動作状況でもＱｏＳを多段階に設定することができる。多段階のＱｏＳは、マイクロプロセッサ１００の負荷率から決定されるので、負荷率に応じてＱｏＳを調整することができる。

本実施例では、アイドルタスクの内容を区分して、ＨＴ０がメインタスクＡをＨＴ１がアイドルタスクＢを実行している場合、そのアイドルタスクＢが比較的重要なアイドルタスクかそうでないかに応じて、ＱｏＳを変えるマイクロプロセッサ１００について説明する。ＨＴ０がアイドルタスクＡを、ＨＴ１がメインタスクＢをそれぞれ実行している場合も同様である。

アイドルタスクには、Ｉ／ＯレジスタやＲＡＭの内容をチェックして値に変化がないかどうかを確認する比較的重要なアイドル処理（以下、フェールセーフ処理という）と、メインタスクを待つ（ポーリング状態）だけのアイドル処理（以下、無限ループ処理というお）がある。無限ループ処理に対し割り当てられるＱｏＳが減少して処理速度が低下しても問題はないが、フェールセーフ処理はある一定期間内に処理を終了させる必要があるため、ＱｏＳが減少して処理速度が低下することは好ましくない。

そこで、本実施例では、マイクロプロセッサ１００が、アイドルタスクがフェールセーフ処理か、無限ループ処理かを区別して、ＱｏＳを切り替えることで、フェールセーフ処理のアイドルタスクには大きなＱｏＳが割り当てられるようにする。

図２９は、マイクロプロセッサ１００の概略構成図の一例を示す。図２９において、図２０と同一部には同一の符号を付しその説明は省略する。図２９に示すように、アイドルタスクＡは、アイドルタスクＡ１とアイドルタスクＡ２を、アイドルタスクＢは、アイドルタスクＢ１とアイドルタスクＢ２を、有する。アイドルタスクＡ１とアイドルタスクＢ１がフェールセーフ処理、アイドルタスクＡ２とアイドルタスクＢ２が無限ループ処理、であるとする。

また、ＴａｓｋＩＤ監視装置４１には、カレントＴａｓｋＩＤレジスタ１，２，アイドルタスクＩＤレジスタ１〜４が接続されている。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）ＯＳ３７のスケジューラがメインタスクＡ、アイドルタスクＡ、メインタスクＢ及びアイドルタスクＢの状態を管理して、現在実行中のタスクのタスクＩＤをカレントＴａｓｋＩＤレジスタに設定する。
（２）ＯＳ３７等の管理ソフト２０が、アイドルタスクＡ１、Ａ２、Ｂ１、Ｂ２のタスクＩＤをアイドルＴａｓｋＩＤレジスタ１〜４に設定する。
（３）ＴａｓｋＩＤ監視装置４１が、カレントＴａｓｋＩＤレジスタとアイドルＴａｓｋＩＤレジスタ１〜４に設定された値を比較して、切り替え要求信号を出力する。

こうすることで、メインタスクとアイドルタスクが並行して実行されている状態で、アイドルタスクの内容に応じてＱｏＳを適切に切り替えることができる。

なお、本実施例では、ＴａｓｋＩＤ監視装置４１が動作状況を判定するが、アドレス監視装置３３、アドレス監視装置３３＋割り込み判断装置３５，又は、Hook処理のいずれでも動作状況を判定できる。

〔レジスタについて〕
図２９では、スケジュール制御装置１６にスケジュールレジスタ１〜４及びデフォルトレジスタが接続されている。スケジュールレジスタ１〜４には、メインタスクとアイドルタスクが並行して実行されている状態のＱｏＳが設定される。設定される値は、例えば、以下のようになる。
スケジュールレジスタ１：第一のＱｏＳ
ＨＴ０がメインタスクＡを、ＨＴ１がアイドルタスクＢ１を実行している場合のＱｏＳ（例えば、７０：３０）。
スケジュールレジスタ２：第二のＱｏＳ
ＨＴ０がメインタスクＡを、ＨＴ１がアイドルタスクＢ２を実行している場合のＱｏＳ（例えば、９０：１０）。
スケジュールレジスタ３：第三のＱｏＳ
ＨＴ０がアイドルタスクＡ１を、ＨＴ１がメインタスクＢを実行している場合のＱｏＳ（例えば、３０：７０）。
スケジュールレジスタ４：第四のＱｏＳ
ＨＴ０がアイドルタスクＡ２を、ＨＴ１がメインタスクＢを実行している場合のＱｏＳ（例えば、１０：９０）。
これらの値は、管理ソフト２０が起動時に設定する。

また、カレントＴａｓｋＩＤレジスタ１，２に設定される値は、図２０と同じ、ＨＴが現在実行しているタスクのタスクＩＤである。

また、アイドルＴａｓｋＩＤレジスタ１にはアイドルタスクＡ１のタスクＩＤが、アイドルＴａｓｋＩＤレジスタ２にはアイドルタスクＡ２のタスクＩＤが、アイドルＴａｓｋＩＤレジスタ３にはアイドルタスクＢ１のタスクＩＤが、アイドルＴａｓｋＩＤレジスタ４にはアイドルタスクＢ２のタスクＩＤが、それぞれ設定される。

上記のように、ＯＳ３７のスケジューラは各タスクにユニークなタスクＩＤを割り当て、タスクＩＤで各タスクを識別している。本実施例では、ソフトウェア開発者がアイドルタスクＡ、Ｂを処理内容に応じて区分しておき、ＯＳ３７がアイドルタスクＡ１，Ａ２、Ｂ１，Ｂ２を管理するものとする。ＯＳ３７等の管理ソフト２０は、スケジューラからタスクＩＤを取得して、例えば、機能統合ＥＣＵ２００の起動時に、アイドルＴａｓｋＩＤレジスタ１にアイドルタスクＡ１のタスクＩＤを、アイドルＴａｓｋＩＤレジスタ２にアイドルタスクＡ２のタスクＩＤを、アイドルＴａｓｋＩＤレジスタ３にアイドルタスクＢ１のタスクＩＤを、アイドルＴａｓｋＩＤレジスタ４にアイドルタスクＢ２のタスクＩＤを、それぞれ設定する。

よって、カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ１又は２の比較結果、及び、カレントＴａｓｋＩＤレジスタ２の値とアイドルＴａｓｋＩＤレジスタ３又は４の比較結果から、ＴａｓｋＩＤ監視装置４１はプログラムＡ、Ｂの動作状況を特定できる。

〔ＴａｓｋＩＤ監視装置４１による動作状況の判定〕
ＴａｓｋＩＤ監視装置４１は、例えば、機能統合ＥＣＵ２００の電源がオンになるとプログラムＡ、Ｂの動作状況の判定を開始する。
図３０は、ＴａｓｋＩＤ監視装置４１の機能を模式的に示す図の一例である。ＴａｓｋＩＤ監視装置４１の比較器３４には、アイドルＴａｓｋＩＤレジスタ１〜４、カレントＴａｓｋＩＤレジスタ１、２が接続されている。

比較器３４は、例えば、入力側のいずれかのレジスタの値が変化した場合、又は、１クロック毎に、比較を実行する。
比較器３４は、カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ１の値を比較する。一致した場合、ＨＴ０はアイドルタスクＡ１を実行していることになる。一致しない場合、比較器３４は、カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ２の値を比較する。一致した場合、ＨＴ０はアイドルタスクＡ２を実行していることになる。どちらも一致しない場合、ＨＴ０はメインタスクＡを実行していることになる。

比較器３４は、カレントＴａｓｋＩＤレジスタ２の値とアイドルＴａｓｋＩＤレジスタ３の値を比較する。一致した場合、ＨＴ１はアイドルタスクＢ１を実行していることになる。一致しない場合、比較器３４は、カレントＴａｓｋＩＤレジスタ２の値とアイドルＴａｓｋＩＤレジスタ４の値を比較する。一致した場合、ＨＴ１はアイドルタスクＢ２を実行していることになる。どちらも一致しない場合、ＨＴ１はメインタスクＢを実行していることになる。

このように、ＴａｓｋＩＤ監視装置４１は、プログラムＡ、Ｂの動作状況を判別できる。ＴａｓｋＩＤ監視装置４１は、以下の切り替え要求信号をスケジュール制御装置１６に出力する。
・ＨＴ０がメインタスクＡ、ＨＴ１がアイドルタスクＢ１を実行している場合、第一のＱｏＳを指示する切り替え要求信号
・ＨＴ０がメインタスクＡ、ＨＴ１がアイドルタスクＢ２を実行している場合、第二のＱｏＳを指示する切り替え要求信号
・ＨＴ０がアイドルタスクＡ１を、ＨＴ１がメインタスクＢを実行している場合、第三のＱｏＳを指示する切り替え要求信号
・ＨＴ０がアイドルタスクＡ２を、ＨＴ１がメインタスクＢを実行している場合、第四のＱｏＳを指示する切り替え要求信号
なお、これまでと同様、動作状況Iでは、ＴａｓｋＩＤ監視装置４１はデフォルトレジスタのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IVでは、ＴａｓｋＩＤ監視装置４１は切り替え要求信号をスケジュール制御装置１６に出力しない。

〔プログラムの動作状況とＱｏＳの関係〕
図３１は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。同じ動作状況でも、ＱｏＳが異なっていることが分かる。

タスク変化Ｉ： 動作状況III→I
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＢのタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。この場合、動作状況はＩになる。よって、ＴａｓｋＩＤ監視装置４１は、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（５０：５０）に設定する。

タスク変化II： 動作状況I→II
メインタスクＡの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＡ１のタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。したがって、アイドルＴａｓｋＩＤレジスタ１のタスクＩＤとカレントＴａｓｋＩＤレジスタ１のタスクＩＤが一致する。また、ＨＴ１はメインタスクＢを実行している。よって、ＴａｓｋＩＤ監視装置４１は、第三のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（３０：７０）に設定する。

タスク変化III： 動作状況II→III
メインタスクＡの実行が開始することでアイドルタスクＡの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＡのタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ１の値は一致しない。また、メインタスクＢの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＢ２のタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。よって、ＴａｓｋＩＤ監視装置４１は、第一のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（９０：１０）に設定する。

タスク変化IV： 動作状況III→IV
メインタスクＡの実行が完了すると、ＯＳ３７のスケジューラは、アイドルタスクＡ２のタスクＩＤをカレントＴａｓｋＩＤレジスタ１に設定する。したがって、アイドルＴａｓｋＩＤレジスタ２のタスクＩＤとカレントＴａｓｋＩＤレジスタ１のタスクＩＤが一致する。また、ＨＴ１はアイドルタスクＢ２を実行している。よって、ＴａｓｋＩＤ監視装置４１は、切り替え要求信号をスケジュール制御装置１６に出力しない。よって、ＱｏＳは（９０：１０）のままである。

タスク変化V： 動作状況IV→II
メインタスクＢの実行が開始することでアイドルタスクＢの実行が終了される。ＯＳ３７のスケジューラは、メインタスクＢのタスクＩＤをカレントＴａｓｋＩＤレジスタ２に設定する。また、ＨＴ０はアイドルタスクＡ２を実行している。よって、ＴａｓｋＩＤ監視装置４１は、第四のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。これにより、スケジュール制御装置１６は、ＱｏＳを（１０：９０）に設定する。

以上説明したように、マイクロプロセッサ１００は、メインタスクとアイドルタスクが並行して実行されている状態でも、アイドルタスクの内容に応じてＱｏＳを適切に切り替えることができる。

実施例７では、アイドルタスクＡ、Ｂを内容に応じてフェールセーフ処理と無限ループ処理に分け、ＱｏＳを切り替えた。こうすることで、アイドルタスクであってもマイクロプロセッサ１００がフェールセーフ処理を確実に実行できるようになる。しかしながら、フェールセーフ処理は、ある程度の頻度で実行すれば十分であり、それ以上の実行はフェールセーフ処理の効果が薄れ、消費電力が増大する。

そこで、本実施例では、単位時間のフェールセーフ処理の回数をカウントし、規定回数以上の場合は、アイドルタスクをキャンセルする、すなわちアイドルタスクのＱｏＳを「０」にするマイクロプロセッサ１００について説明する。

図３２は、マイクロプロセッサ１００の概略構成図の一例を示す。図３２において、図２９と同一部には同一の符号を付しその説明は省略する。図３２では、ＯＳ３７がカウンタＡとカウンタＢを有する。ＯＳ３７がソフト的にカウントするのでなく、ＴａｓｋＩＤレジスタにカウンタＡ，Ｂを設け、ＯＳ３７からの指示がある度に値をインクリメントしてもよい。また、ＴａｓｋＩＤ監視装置４１は、フラグＡ、Ｂを有する。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）ＯＳ３７のスケジューラがメインタスクＡ、アイドルタスクＡ、メインタスクＢ及びアイドルタスクＢの状態を管理して、現在実行中のタスクのタスクＩＤをカレントＴａｓｋＩＤレジスタに設定する。
（２）ＯＳ３７等の管理ソフト２０が、アイドルタスクＡ１、Ａ２、Ｂ１、Ｂ２のタスクＩＤをアイドルＴａｓｋＩＤレジスタ１〜４に設定する。
（３）ＯＳ３７が単位時間のアイドルタスクの実行回数（実行頻度）をカウントし、フラグＡ又はＢをオンにする。
（４）ＴａｓｋＩＤ監視装置４１は、カレントＴａｓｋＩＤレジスタとアイドルＴａｓｋＩＤレジスタ１〜４に設定された値を比較して、動作状況I〜IVを判定する。
（５）動作状況II又はIIIの場合、ＴａｓｋＩＤ監視装置４１はフラグＡ、Ｂの状態を監視して、切り替え要求信号を出力する。

こうすることで、メインタスクとアイドルタスクが並行して実行されている状態で、フェールセーフ処理のアイドルタスクを過不足なく実行できるよう適切なＱｏＳに切り替えることができる。

〔フラグＡ、Ｂ〕
フラグＡは、アイドルタスクＡ１（フェールセーフ処理）が単位時間に規定回数以上、実行された場合にオンになるフラグである。（規定回数以上でないとオフになる）。フラグＢは、アイドルタスクＢ１（フェールセーフ処理）が単位時間に規定回数以上、実行された場合にオンになるフラグである。（規定回数以上でないとオフになる）。

具体的には、例えばＯＳ３７のスケジューラが、単位時間毎に初期化しながらアイドルタスクＡ１、Ｂ１の実行回数をカウントして、単位時間が経過すると規定回数と比較する。そして、ＯＳ３７は、アイドルタスクＡ１の実行回数が規定回数以上ならフラグＡをオンにして、アイドルタスクＢ１の実行回数が規定回数以上ならフラグＢをオンにする。

〔レジスタについて〕
レジスタの種類は図２９と同様であるが、設定される値が異なる。設定される値は、例えば、以下のようになる。
スケジュールレジスタ１：第一のＱｏＳ
ＨＴ０がメインタスクＡを実行し、ＨＴ１が、フラグＢが「オフ」の状態で、アイドルタスクＢ１を実行している場合のＱｏＳ（例えば、７０：３０）。
スケジュールレジスタ２：第二のＱｏＳ
・ＨＴ０がメインタスクＡを実行し、ＨＴ１が、フラグＢが「オン」の状態で、アイドルタスクＢ１を実行している場合のＱｏＳ。
・ＨＴ０がメインタスクＡを実行し、ＨＴ１がアイドルタスクＢ２を実行している場合のＱｏＳ。

第二のＱｏＳは例えば（１００：０）である。これにより、規定回数以上のフェールセーフ処理及び数に関係なく、本来の処理以外の無限ループ処理の実行を禁止できる。
スケジュールレジスタ３：第三のＱｏＳ
フラグＡが「オフ」の状態で、ＨＴ０がアイドルタスクＡ１を、ＨＴ１がメインタスクＢを実行している場合のＱｏＳ（例えば、３０：７０）。
スケジュールレジスタ４：第四のＱｏＳ
・フラグＡが「オン」の状態で、ＨＴ０がアイドルタスクＡ１を、ＨＴ１がメインタスクＢを実行している場合のＱｏＳ。
ＨＴ０がアイドルタスクＡ２を、ＨＴ１がメインタスクＢを実行している場合のＱｏＳ。

第四のＱｏＳは例えば（０：１００）である。これにより、規定回数以上のフェールセーフ処理及び数に関係なく無限ループ処理の実行を禁止できる。
これらの値は、管理ソフト２０が起動時に設定する。

〔ＴａｓｋＩＤ監視装置４１による動作状況の判定〕
ＴａｓｋＩＤ監視装置４１は、例えば、機能統合ＥＣＵ２００の電源がオンになるとプログラムＡ、Ｂの動作状況の判定を開始する。なお、本実施例では、ＴａｓｋＩＤ監視装置４１が動作状況を判定するが、アドレス監視装置３３、アドレス監視装置３３＋割り込み判断装置３５，又は、Hook処理のいずれでも動作状況を判定できる。

図３３は、ＴａｓｋＩＤ監視装置４１の機能を模式的に示す図の一例である。図３３において図３０と同一部の説明は省略する。図３３では、比較器３４にフラグＡとフラグＢが接続されている。

実施例７と同様に、比較器３４は、ＨＴ０がアイドルタスクＡ１を実行しているか、ＨＴ０がアイドルタスクＡ２を実行しているか、又は、ＨＴ０がメインタスクＡを実行しているか、を判定する。同様に、比較器３４は、ＨＴ１がアイドルタスクＢ１を実行しているか、ＨＴ１がアイドルタスクＢ２を実行しているか、又は、ＨＴ１がメインタスクＢを実行しているか、を判定する。

そして、比較器３４は、ＨＴ０がアイドルタスクＡ１を実行し、ＨＴ１がメインタスクＢを実行している場合、フラグＡが「オン」か「オフ」かを判定する。フラグＡが「オン」の場合、ＴａｓｋＩＤ監視装置４１は、第四のＱｏＳを指示する切り替え要求信号を出力する。フラグＡが「オフ」の場合、ＴａｓｋＩＤ監視装置４１は、第三のＱｏＳを指示する切り替え要求信号を出力する。

比較器３４は、ＨＴ０がメインタスクＡを実行し、ＨＴ１がアイドルタスクＢ１を実行している場合、フラグＢが「オン」か「オフ」かを判定する。フラグＢが「オン」の場合、ＴａｓｋＩＤ監視装置４１は、第二のＱｏＳを指示する切り替え要求信号を出力する。フラグＢが「オフ」の場合、ＴａｓｋＩＤ監視装置４１は、第一のＱｏＳを指示する切り替え要求信号を出力する。

なお、ＨＴ０がアイドルタスクＡ２（無限ループ処理）を実行し、ＨＴ１がメインタスクＢを実行している場合、ＴａｓｋＩＤ監視装置４１は、第四のＱｏＳを指示する切り替え要求信号を出力する。ＨＴ０がメインタスクＡを実行し、ＨＴ１がアイドルタスクＢ２（無限ループ処理）を実行している場合、ＴａｓｋＩＤ監視装置４１は、第二のＱｏＳを指示する切り替え要求信号を出力する。

なお、これまでと同様、動作状況Iでは、ＴａｓｋＩＤ監視装置４１はデフォルトレジスタのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。動作状況IVでは、ＴａｓｋＩＤ監視装置４１は切り替え要求信号をスケジュール制御装置１６に出力しない。

〔プログラムの動作状況とＱｏＳの関係〕
図３４は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。同じ動作状況でも、ＱｏＳが異なっていることが分かる。

動作状況III（ＨＴ０：メインタスクＡ、ＨＴ１：アイドルタスクＢ１、フラグＢ：オフ）
フラグＢがオフなので、アイドルタスクＢ１が十分に実行されていないことになる。このため、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（７０：３０）に設定する。

動作状況I（ＨＴ０：メインタスクＡ、ＨＴ１：メインタスクＢ）
ＨＴ０とＨＴ１が共にメインタスクを実行しているので、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（５０：５０）に設定する。

動作状況II（ＨＴ０：アイドルタスクＡ１、ＨＴ１：メインタスクＢ、フラグＡ：オフ）
フラグＡがオフなので、アイドルタスクＡ１が十分に実行されていないことになる。このため、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（３０：７０）に設定する。

動作状況III（ＨＴ０：メインタスクＡ、ＨＴ１：アイドルタスクＢ１、フラグＢ：オン）
フラグＢがオンなので、アイドルタスクＢ１が十分に実行されたことになる。このため、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（１００：０）に設定する。

動作状況IV（ＨＴ０：アイドルタスクＡ１、ＨＴ１：アイドルタスクＢ１）
ＨＴ０とＨＴ１が共にアイドルタスクを実行しているので、ＴａｓｋＩＤ監視装置４１は切り替え要求信号を出力しない。よって、ＱｏＳは（１００：０）のままである。

動作状況II（ＨＴ０：アイドルタスクＡ１、ＨＴ１：メインタスクＢ、フラグＡ：オン）
フラグＡがオンなので、アイドルタスクＡ１が十分に実行されたことになる。このため、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（０：１００）に設定する。

以上説明したように、マイクロプロセッサ１００は、メインタスクとアイドルタスクが並行して実行されている状態において、重要なアイドルタスクの実行頻度を監視してその結果に応じてＱｏＳを切り替えることで、ハードウェアリソースを効率よく使用することができる。

これまでの実施例ではメインタスクＡとメインタスクＢが並行に実行される場合、デフォルトのＱｏＳが割り当てられると説明した。しかしながら、メインタスクＡとメインタスクＢの一方の優先度が高い場合があり、この場合には優先度の高いメインタスクに多くのＱｏＳが割り当てられることが好ましいといえる。

図３５は、本実施例の課題を説明する図の一例である。一般に車両の制御用のＥＣＵには、周期処理の間に、必ず実行されるべき高優先度メインタスクと、一部処理しなくても問題のない低優先度タスクとに、分割されたメインタスクが搭載されることがある。ＨＭＴのマイクロプロセッサ１００では、プログラムＡの高優先度タスクＡとプログラムＢの高優先度タスクＢが並行して実行されることもある。図３５では網線の部分がメインタスクＡの高優先度タスクと、プログラムＢの高優先度タスクが並行して実行されている（以下、この状況を高優先競合状況という）。高優先競合状況では、どちらのプログラムも１００％のＱｏＳを要求するため、リソースの配分が困難になりやすい。

そこで、本実施例では、高優先競合状況をハード的に回避するマイクロプロセッサ１００について説明する。

図３６は、マイクロプロセッサ１００の概略構成図の一例を示す。図３６において、図２９と同一部には同一の符号を付しその説明は省略する。図３６に示すように、メインタスクＡは、高優先度タスクＡと低優先度タスクＡを、メインタスクＢは、高優先度タスクＢと低優先度タスクタスクＢを、有する。なお、さらに、実施例８と同様にアイドルタスクＡ、Ｂをそれぞれフェールセーフ処理と無限ループ処理に分割してもよい。

また、ＴａｓｋＩＤ監視装置４１には、カレントＴａｓｋＩＤレジスタ１，２，アイドルタスクＩＤレジスタ１、２及び高優先度ＴａｓｋＩＤレジスタ１，２が接続されている。また、スケジュール制御装置１６には、スケジュールレジスタ１〜３及びデフォルトレジスタが接続されている。

本実施例のマイクロプロセッサ１００の概略的な特徴部は次のようになる。
（１）ＯＳ３７のスケジューラがメインタスクＡ（高優先度タスクＡと低優先度タスクＡ）、アイドルタスクＡ、メインタスクＢ（高優先度タスクＢと低優先度タスクＢ）及びアイドルタスクＢの状態を管理して、現在実行中のタスクのタスクＩＤをカレントＴａｓｋＩＤレジスタに設定する。
（２）ＯＳ３７等の管理ソフト２０が、高優先度タスクＡ、ＢのタスクＩＤを高優先度タスクＩＤレジスタ１、２に設定する。ＯＳ３７等の管理ソフト２０が、アイドルタスクＡ、ＢのタスクＩＤをアイドルＴａｓｋＩＤレジスタ１、２に設定する。
（３）ＴａｓｋＩＤ監視装置４１が、カレントＴａｓｋＩＤレジスタと高優先ＴａｓｋＩＤレジスタ１、２に設定された値を比較して、切り替え要求信号を出力する。

こうすることで、高優先度タスクＡと高優先度タスクＢが並行して実行されている状態で、より優先的に実行すべきメインタスクに好ましいＱｏＳを割り当てることができる。なお、本実施例では説明のため、高優先度タスクＡは高優先度タスクＢよりも優先度が高く設定されているものとする。

〔レジスタについて〕
スケジュールレジスタ１と２に設定される値は例えば実施例２と同じである。すなわち、一方がメインタスクで他方がアイドルタスクの動作状況に対応して、以下の値が設定される。
スケジュールレジスタ１：第一のＱｏＳ
スケジュールレジスタ２：第二のＱｏＳ
これに対しスケジュールレジスタ３には以下の値が設定される。
スケジュールレジスタ３：高優先競合状況のＱｏＳ
本実施例は「高優先度タスクＡは高優先度タスクＢよりも優先度が高い」と仮定したので、スケジュールレジスタ３は１つあればよい。スケジュールレジスタ３に設定される値は、高優先競合状況のＱｏＳ＝（１００：０）である。

本実施例では、スケジュールレジスタ１には第一のＱｏＳ＝（８０：２０）が、スケジュールレジスタ２には第二のＱｏＳ＝（２０：８０）が、設定される。

カレントＴａｓｋＩＤレジスタ１，２に設定される内容は、ＨＴが現在実行しているタスクのタスクＩＤである。

高優先ＴａｓｋＩＤレジスタ１には高優先度タスクＡのタスクＩＤが、高優先ＴａｓｋＩＤレジスタ２には高優先度タスクＢのタスクＩＤが、それぞれ設定される。また、アイドルＴａｓｋＩＤレジスタ１にはアイドルタスクＡのタスクＩＤが、アイドルＴａｓｋＩＤレジスタ２にはアイドルタスクＢのタスクＩＤが、それぞれ設定される。

ＯＳ３７等の管理ソフト２０は、例えば、機能統合ＥＣＵ２００の起動時に、高優先ＴａｓｋＩＤレジスタ１に高優先度タスクＡのタスクＩＤを、高優先ＴａｓｋＩＤレジスタ２に高優先度タスクＢのタスクＩＤを、アイドルＴａｓｋＩＤレジスタ１にアイドルタスクＡのタスクＩＤを、アイドルＴａｓｋＩＤレジスタ２にアイドルタスクＢのタスクＩＤを、それぞれ設定する。

よって、カレントＴａｓｋＩＤレジスタ１の値とアイドルＴａｓｋＩＤレジスタ１の比較結果により、ＴａｓｋＩＤ監視装置４１はＨＴ０がメインタスクＡを実行しているか又はアイドルタスクＡを実行しているかを特定できる。さらに、ＴａｓｋＩＤ監視装置４１は、ＨＴ０がメインタスクＡを実行している場合、カレントＴａｓｋＩＤレジスタ１の値と高優先度タスクＩＤレジスタ１の値を比較することで、ＨＴ０が高優先度タスクＡを実行しているか否かを判定できる。ＨＴ１についても同様である。

〔ＴａｓｋＩＤ監視装置４１による動作状況の判定〕
ＴａｓｋＩＤ監視装置４１は、例えば、機能統合ＥＣＵ２００の電源がオンになるとプログラムＡ、Ｂの動作状況の判定を開始する。
図３７は、ＴａｓｋＩＤ監視装置４１の機能を模式的に示す図の一例である。ＴａｓｋＩＤ監視装置４１の比較器３４には、アイドルＴａｓｋＩＤレジスタ１、２、高優先ＴａｓｋＩＤレジスタ１，２及びカレントＴａｓｋＩＤレジスタ１、２が接続されている。

比較器３４は、例えば、入力側のいずれかのレジスタの値が変化した場合、又は、１クロック毎に、比較を実行する。

図３８は、比較器３４の比較によって得られる動作状況の一例を示す図である。動作状況Ｉ〜IVに区分されると共に、動作状況Iがさらに動作状況I1〜I4に区分されている。
動作状況I1：メインタスクＡが高優先度タスクＡ、メインタスクＢが高優先度タスクＢ
動作状況I2：メインタスクＡが低優先度タスクＡ、メインタスクＢが高優先度タスクＢ
動作状況I3：メインタスクＡが高優先度タスクＡ、メインタスクＢが低優先度タスクＢ
動作状況I4：メインタスクＡが低優先度タスクＡ、メインタスクＢが低優先度タスクＢ
なお、メインタスクＡとアイドルタスクＢが並行に実行される動作状況III、アイドルタスクＡとメインタスクＢが並行に実行される動作状況II、又は、アイドルタスクＡとアイドルタスクＢが並行に実行される動作状況IV、の切り替え要求信号については、例えば実施例２と同様なので説明を省略する。

ＴａｓｋＩＤ監視装置４１は、動作状況I1又はI3であると判定すると、第三のＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。ＴａｓｋＩＤ監視装置４１は、動作状況I2であると判定すると、デフォルトのＱｏＳを指示する切り替え要求信号をスケジュール制御装置１６に出力する。ＴａｓｋＩＤ監視装置４１は、動作状況I4であると判定すると、切り替え要求信号をスケジュール制御装置１６に出力しない。

〔プログラムの動作状況とＱｏＳの関係〕
図３９は、プログラムの動作状況とＱｏＳの関係の一例を示す図である。
・動作状況IV（ＨＴ０：アイドルタスクＡ、ＨＴ１：アイドルタスクＢ）
ＨＴ０とＨＴ１が共にアイドルタスクを実行しているので、直前のＱｏＳが維持される。このため、ＱｏＳは（５０：５０）になっている。
・動作状況III（ＨＴ０：高優先度タスクＡ、ＨＴ１：アイドルタスクＢ）
スケジュール制御装置１６は、これまでの実施例と同様、切り替え要求信号を受けて、ＱｏＳを（８０：２０）に設定する。
・動作状況I1（ＨＴ０：高優先度タスクＡ、ＨＴ１：高優先度タスクＢ）
高優先度タスクＡは、高優先度タスクＢよりも優先されるので、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（１００：０）に設定する。この結果、実際には動作状況I1では、プログラムＢは実行されない。
・動作状況I2（ＨＴ０：低優先度タスクＡ、ＨＴ１：高優先度タスクＢ）
ＨＴ０が高優先度タスクＡの実行を終えて、低優先度タスクＡの実行を開始する。高優先度タスクＢと低優先度タスクＡは特に優先関係がないものとして、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（５０：５０）に設定する。
・動作状況II（ＨＴ０：アイドルタスクＡ、ＨＴ１：低優先度タスクＢ）
スケジュール制御装置１６は、これまでの実施例と同様、切り替え要求信号を受けて、ＱｏＳを（２０：８０）に設定する。
・動作状況III（ＨＴ０：高優先度タスクＡ、ＨＴ１：アイドルタスクＢ）
スケジュール制御装置１６は、これまでの実施例と同様、切り替え要求信号を受けて、ＱｏＳを（８０：２０）に設定する。
・動作状況I1（ＨＴ０：高優先度タスクＡ、ＨＴ１：高優先度タスクＢ）
高優先度タスクＡは、高優先度タスクＢよりも優先されるので、スケジュール制御装置１６は、切り替え要求信号を受けて、ＱｏＳを（１００：０）に設定する。実際には動作状況I1では、プログラムＢは実行されない。

以上説明したように、マイクロプロセッサ１００は、メインタスクとアイドルタスクが並行して実行されている状態において、ＨＴ０とＨＴ１のメインタスクの重要度に応じてＱｏＳを切り替えることで、より優先的に実行すべきメインタスクを優先的に実行することができる。

本実施形態のマイクロプロセッサは、個別だったＥＣＵを、ＨＭＴ機能を有するＥＣＵに機能統合した場合、タスク内容に応じてＨＴ間のＱｏＳを適切に切り替えることができる。

１１ 命令バッファ
１２ 命令デコーダ
１３ レジスタ群
１４ 演算器
１５ ＬＳＵ
１６ スケジュール制御装置
１７ パイプライン制御装置
１８ ソフトウェア監視装置
１９ マルチプレクサ
２０ 管理ソフト
２２ バス
２３ 命令記憶部
２４ データ記憶部
２５ 命令フェッチバス
２６ データアクセスバス
３３ アドレス監視装置
３４ 比較器
３５ 割り込み判断装置
３６ ＩＮＴＣ
３７ ＯＳ
３８ Ｈｏｏｋ監視装置
３９ スケジュール切り替えレジスタ
４１ ＴａｓｋＩＤ監視装置
１００ マイクロプロセッサ
２００ 機能統合ＥＣＵ

Claims (15)

1. ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、前記ｎ個のプログラムを実行するマイクロプロセッサであって、
   前記ｎ個のプログラムそれぞれのメインタスク、及び、アイドルタスク、を記憶した記憶手段と、
   前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、
   各ハードウェアスレッドによる前記ｎ個のプログラムの実行アドレスと、前記記憶手段における各アイドルタスクのアドレス情報、を比較する比較手段と、
   前記比較手段の比較結果に基づき、前記ｎ個のプログラムの動作状況を監視し、該動作状況に応じた目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、
   を有することを特徴とするマイクロプロセッサ。
2. 割り込みコントローラから受け付けた割り込み情報に応じて、前記ｎ個のメインタスクのいずれかを対応する前記ｎ個のハードウェアスレッドのいずれかに開始させる割り込み制御手段を有し、
   前記目標実行比率指示手段は、前記割り込み制御手段から取得した、前記ｎ個のメインタスクのいずれかの割り込み実行の通知に基づき、前記動作状況を判定する、
   ことを特徴とする請求項１記載のマイクロプロセッサ。
3. ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、前記ｎ個のプログラムを実行するマイクロプロセッサであって、
   前記ｎ個のプログラムそれぞれのメインタスク、アイドルタスク、及び、ＯＳを記憶した記憶手段と、
   前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、
   前記ｎ個のメインタスクそれぞれの開始と終了、又は、前記ｎ個のアイドルタスクそれぞれの開始と終了、を前記ＯＳが提供する機能にて検出する開始終了検出手段と、
   前記開始終了検出手段が検出した、前記ｎ個のアイドルタスクの開始情報又は終了情報を記憶する動作状態記憶手段と、
   前記動作状態記憶手段の記憶結果により定まる、前記ｎ個のプログラムの動作状況に応じた目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、
   を有することを特徴とするマイクロプロセッサ。
4. ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、前記ｎ個のプログラムを実行するマイクロプロセッサであって、
   前記ｎ個のプログラムそれぞれのメインタスク、アイドルタスク、及び、ＯＳを記憶した記憶手段と、
   前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、
   前記ｎ個のアイドルタスクのタスクＩＤを記憶する前記ｎ個の第１のレジスタと、
   各ハードウェアスレッド毎に、実行しているタスクのタスクＩＤを前記ｎ個の第２のレジスタに登録タスクＩＤ登録手段と、
   ハードウェアスレッド毎に、前記第１のレジスタの値と前記第２のレジスタの値を比較する比較手段と、
   前記比較手段の比較結果に基づき、前記ｎ個のプログラムの動作状況を監視し、該動作状況に応じた目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、
   を有することを特徴とするマイクロプロセッサ。
5. 前記ｎ個のプログラムの実行比率を監視する実行比率監視手段と、
   前記動作状況に対応づけて前記実行比率を登録した実行比率テーブルと、を有し、
   前記目標実行比率指示手段は、監視の結果の前記動作状況に対応づけられた、前記実行比率テーブルの前記実行比率と閾値を比較して、前記目標実行比率を決定する、
   ことを特徴とする請求項１〜４いずれか１項記載のマイクロプロセッサ。
6. ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、前記ｎ個のプログラムを実行するマイクロプロセッサであって、
   前記ｎ個のプログラムそれぞれのメインタスク、及び、アイドルタスク、を記憶した記憶手段と、
   前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、
   前記ｎ個のハードウェアスレッドのそれぞれが実行しているのが、メインタスク、アイドルタスクのフェールセーフ処理タスク又は非フェールセーフ処理タスク、のいずれかに基づき、前記ｎ個のプログラムの動作状況を判定する比較手段と、
   前記ｎ個のハードウェアスレッドのそれぞれが実行しているのが、メインタスク、フェールセーフ処理タスク又は非フェールセーフ処理タスクのいずれかに応じて、目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、
   を有することを特徴とするマイクロプロセッサ。
7. 前記目標実行比率指示手段は、
   第１のハードウェアスレッドが第１のメインタスクを実行し、第２のハードウェアスレッドが第２のアイドルタスクのフェールセーフ処理タスクを実行している場合、
   前記第１のハードウェアスレッドが前記第１のメインタスクを実行し、前記第２のハードウェアスレッドが前記第２のアイドルタスクの非フェールセーフ処理タスクを実行している場合よりも、第１のプログラムよりも第２のプログラムに割り当てられる値が大きい目標実行比率を前記スケジュール制御手段に指示する、
   ことを特徴とする請求項６記載のマイクロプロセッサ。
8. 前記第１のアイドルタスクのフェールセーフ処理タスクの第１の実行頻度、及び、前記第２のアイドルタスクのフェールセーフ処理タスクの第２の実行頻度、をカウントするカウント手段を有し、
   前記第１の実行頻度が閾値未満の場合、
   前記目標実行比率指示手段は、前記第１のハードウェアスレッドが前記第１のメインタスクを実行し、前記第２のハードウェアスレッドが前記第２のアイドルタスクのフェールセーフ処理タスクを実行している場合、前記第１のハードウェアスレッドが前記第１のメインタスクを実行し、前記第２のハードウェアスレッドが前記第２のアイドルタスクの非フェールセーフ処理タスクを実行している場合よりも、前記第２のプログラムに割り当てられる値が大きい目標実行比率を前記スケジュール制御手段に指示し、
   前記第１の実行頻度が閾値以上の場合、
   前記目標実行比率指示手段は、前記第１のハードウェアスレッドが前記第１のメインタスクを実行し、前記第２のハードウェアスレッドが前記第２のアイドルタスクのフェールセーフ処理タスクを実行している場合でも、前記第２のプログラムに割り当てられる値がゼロの目標実行比率を前記スケジュール制御手段に指示する、
   ことを特徴とする請求項６記載のマイクロプロセッサ。
9. ｎ（２以上の自然数）個のハードウェアスレッドを切り替えて、前記ｎ個のプログラムを実行するマイクロプロセッサであって、
   前記ｎ個のプログラムそれぞれのメインタスク、及び、アイドルタスク、を記憶した記憶手段と、
   前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、
   前記ｎ個のハードウェアスレッドのそれぞれが、メインタスクの高優先度タスク、メインタスクの低優先度タスク、又は、アイドルタスク、のいずれを実行しているかに応じて、前記ｎ個のプログラムの動作状況を判定する比較手段と、
   前記ｎ個のハードウェアスレッドのそれぞれが実行しているのが、メインタスクの高優先度タスク、メインタスクの低優先度タスク、又は、アイドルタスク、のいずれかに応じて、目標実行比率を前記スケジュール制御手段に指示する目標実行比率指示手段と、
   を有することを特徴とするマイクロプロセッサ。
10. 前記目標実行比率指示手段は、
    第１のハードウェアスレッドが第１の高優先度タスクを実行し、第２のハードウェアスレッドが第２のメインタスクを実行している場合、
    前記第１のハードウェアスレッドが第１の低優先度タスクを実行し、前記第２のハードウェアスレッドが第２の高優先度タスクを実行している場合よりも、第１のプログラムに割り当てられる値が第２のプログラムよりも大きい目標実行比率を前記スケジュール制御手段に指示する、
    ことを特徴とする請求項９記載のマイクロプロセッサ。
11. 前記目標実行比率指示手段は、
    前記第１のハードウェアスレッドが前記第１の高優先度タスクを実行し、前記第２のハードウェアスレッドが前記第２のメインタスクを実行している場合、前記第１のプログラムに割り当てられる値がゼロの目標実行比率を前記スケジュール制御手段に指示する、
    ことを特徴とする請求項９記載のマイクロプロセッサ。
12. 請求項１〜１１のいずれか1項に記載されたマイクロプロセッサを搭載した、車両の電子制御ユニット。
13. 前記プログラムは、単一スレッド型の電子制御ユニットが実行していたプログラムである、ことを特徴とする請求項１２記載の電子制御ユニット。
14. ｎ（２以上の自然数）個のプログラムをそれぞれ実行する前記ｎ個のハードウェアスレッドと、
    前記ｎ個のプログラムそれぞれのメインタスク、及び、アイドルタスク、を記憶した記憶手段と、
    前記ｎ個のプログラムのそれぞれの目標実行比率に基づき、前記ｎ個のハードウェアスレッドのいずれかに実行権を与えるスケジュール制御手段と、を有するマイクロプロセッサの実行比率切り替え方法であって、
    比較手段が、各ハードウェアスレッドによる前記ｎ個のプログラムの実行アドレスと、前記記憶手段における各アイドルタスクのアドレス情報、を比較するステップと、
    目標実行比率指示手段が、前記比較手段の比較結果に基づき、前記ｎ個のプログラムの動作状況を監視し、該動作状況に応じた目標実行比率を前記スケジュール制御手段に指示するステップと、
    を有することを特徴とする実行比率切り替え方法。
15. 請求項１４に記載されたマイクロプロセッサの実行比率切り替え方法を搭載した、車両の電子制御ユニット。

Images