"複数のアプリケーションと1つ以上の機器とが協働することで複数の機能を提供可能なマイコンにおいて、機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、アプリケーションと協働する機器が登録された機器テーブルと、機器の不具合を検出する不具合検出手段と、不具合機器を使用する第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定する機器特定手段と、特定された機器に復旧処理を行い、復旧処理を行っても前記不具合機器が復旧しない場合、前記第1のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第2のアプリケーションを呼び出して共有機器の故障判定を要求する復旧処理手段と、を有することを特徴とするマイコン。前記第2のアプリケーションが共有機器が故障していると判定した場合、前記復旧処理手段は、該共有機器に復旧処理を行う、ことを特徴とする請求項1記載のマイコン。前記第2のアプリケーションが共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、ことを特徴とする請求項1又は2記載のマイコン。前記復旧処理手段が前記共有機器に復旧処理を行っても、該共有機器が復旧しない場合、前記復旧処理手段は、前記共有機器に復旧困難な故障が生じていると判定する、ことを特徴とする請求項2記載のマイコン。前記第1のアプリケーションが他のアプリケーションと共有する共有機器が複数ある場合において、前記復旧処理手段が前記共有機器に復旧処理を行っても、該共有機器が復旧しない場合、前記復旧処理手段は、前記第1のアプリケーションが他のアプリケーションと共有する第2の共有機器を前記機器テーブルにより特定し、該第2の共有機器の復旧処理が許可された第3のアプリケーションを呼び出して第2の共有機器の故障判定を要求する、ことを特徴とする請求項2記載のマイコン。前記第3のアプリケーションが第2の共有機器が故障していると判定した場合、前記復旧処理手段は、該第2の共有機器に復旧処理を行う、ことを特徴とする請求項5記載のマイコン。前記第3のアプリケーションが第2の共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、ことを特徴とする請求項5記載のマイコン。前記第2のアプリケーションが共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第1のアプリケーションが他のアプリケーションと共有する第2の共有機器を前記機器テーブルにより特定し、該第2の共有機器の復旧処理が許可された第3のアプリケーションを呼び出して第2の共有機器の故障判定を要求する、ことを特徴とする請求項5記載のマイコン。前記第3のアプリケーションが第2の共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、ことを特徴とする請求項8記載のマイコン。機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、アプリケーションと協働する機器が登録された機器テーブルと、を有し、複数のアプリケーションと1つ以上の機器とが協働することで複数の機能を提供可能なマイコンの故障判定方法において、不具合検出手段が、機器の不具合を検出するステップと、機器特定手段が、不具合機器を使用する第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定するステップと、復旧処理手段が、特定された機器に復旧処理を行っても前記不具合機器が復旧しない場合、前記第1のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第2のアプリケーションを呼び出して共有機器の故障判定を要求するステップと、を有することを特徴とする故障判定方法。ところで、車載されるマイコン又は、ECU:ElectronicControlUnitの数が増大してきたことから、複数のECUの機能を統合して1つのECUに統合する試みが行われている。統合ECUには複数の機能が搭載されるため、統合ECUの複数の機能の重要度が同じとは限らない状況が生じうる。例えば、1つの統合ECUが、重要度が低い機能Bとより重要度の高い機能Aを有するような場合が生じる。機能AはアプリAと関係が強く、アプリAが周辺機器を使用して提供される機能であり、機能BはアプリBと関係が強く、アプリBが周辺機器を使用して提供される機能である。このような統合ECUにおいて、機能Bに故障が生じた場合すなわち、アプリBが使用する周辺機器の故障、又は、アプリBの動作の異常を検出した場合に、統合ECUに搭載されたマイコン自体をリセットすると、再起動するまでの間に重要度の高い機能Aが提供されないという不都合が生じる。この不都合を回避するため、機能に関係するアプリCPUや周辺機器のみをリセットすることが考えられる。図1はこのような不都合の回避を説明する図の一例である。図1では上記の回路として、CPUと周辺機器を示した。機能AはCPU0がアプリAを実行し周辺回路0,1を使用することで、機能BはCPU1がアプリBを実行し周辺回路1,2を使用することで、それぞれ提供されている。例えば、機能Bに必要な周辺機器2に不具合が生じた場合、統合ECUが周辺機器2やCPU1をリセットすれば機能Aは影響を受けない。よって、機能に関係するアプリや周辺機器のみをリセットすることで、重要度の高い機能Aが提供されないという不都合を回避できる場合がある。しかし、機能Bに必要な周辺機器1に不具合が生じた場合、統合ECUが周辺機器1をリセットすれば機能Aが影響を受けてしまう。このように共有リソースについては、機能に関係するアプリや周辺機器のみをリセットするだけでは不都合を回避できない。すなわち、統合ECUにおいて重要度の異なる機能が統合された場合、共有されるリソースを安易にリセットすると、重要度の高い機能Aが共有リソースを使用できなくなり、上記の不都合が生じてしまう。そこで、共有リソース以外図1の周辺機器0,2については、各アプリA,Bがリセットの是非を管理し、共有リソース図1の周辺機器1については、重要度の最も高いアプリAのみがリセット可能に設定しておくことが考えられる。しかし、このようにすると、重要度の低いアプリBが周辺機器1の故障を検出した場合に、アプリBは周辺機器1をリセットできないため、機能Bの復旧ができないという不都合が残る。本発明は、上記課題に鑑み、重要度の異なる複数のアプリが統合されたマイコンにおいて、各機能に必要な機器の故障が検出された場合に他の機能の提供を阻害せずに機器を復旧できるマイコンを提供することを目的とする。本発明は、複数のアプリケーションと1つ以上の機器とが協働することで複数の機能を提供可能なマイコンにおいて、機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、アプリケーションと協働する機器が登録された機器テーブルと、機器の不具合を検出する不具合検出手段と、不具合機器を使用する第1のアプリケーションと協働する機器であって第1のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定する機器特定手段と、特定された機器に復旧処理を行い、復旧処理を行っても前記不具合機器が復旧しない場合、前記第1のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第2のアプリケーションを呼び出して共有機器の故障判定を要求する復旧処理手段と、を有することを特徴とするマイコン。重要度の異なる複数のアプリが統合されたマイコンにおいて、各機能に必要な機器の故障が検出された場合に他の機能の提供を阻害せずに機器を復旧できるマイコンを提供することができる。以下、本発明を実施するための形態について図面を参照しながら説明する。概略図2は、マイコンにおける周辺機器の復旧を説明する図の一例である。VCPU0がアプリケーションAを、VCPU1がアプリケーションBをそれぞれ実行している。機能A、機能Bは次のように提供され、機能Aの方が機能Bよりも重要度が高いものとする。機能とアプリケーション以下、アプリという場合があるは対応しているのでアプリAの方がアプリBよりも重要度が高いといってもよい。機能A:アプリAが周辺機器0,1を使用して提供する。機能B:アプリBが周辺機器1,2を使用して提供する。したがって、周辺機器1は共有リソースである。また、VCPU0,1が参照できる場所の復旧処理許可フラグに、周辺機器0~2毎に周辺機器のリセットが許可されたアプリが登録されている。一例として、共有リソースである周辺機器1は、重要度の高いアプリAのみがリセットできるように設定されている。このような構成において、機能Bに必要な周辺機器に不具合が生じると、アプリBは復旧処理許可フラグを参照し、リセットが許可されている周辺機器2だけをリセットする。これにより、機能Bが提供可能になれば復旧処理は終了である。リセットしても機能Bが提供可能とならない場合、機能Bが復旧できないのは周辺機器1に故障が生じたためであることが疑われる。このため、アプリBはアプリAに故障の検出を通知する。アプリAは周辺機器1をリセットすることが許可されているので、アプリAは重要度の高い自己の処理の優先度を保ちながら周辺機器1をリセットする。これにより、周辺機器1が復旧すれば、機能Bの提供が可能になる。したがって、本実施形態のマイコンは、重要度の異なる機能が統合された状態において、統合された機能のうち重要度の低い機能に必要な周辺機器が故障しても、マイコン全体をリセットしないので重要度の高い機能が提供されなくなることがない。また、重要度の低い機能の提供中に、重要度の高い機能が共通に使用する周辺機器が故障した場合以下、機能の故障という場合がある、重要度の低い機能が重要度の高い機能にリセットを要求するので、重要度の高い機能が該周辺機器を復旧させることができる。したがって、重要度の低い機能が使用できない状態が長時間継続することも防止できる。なお、以下では、復旧処理をリセットという。復旧処理は周辺機器を使用できる状態に戻す処理をいうので、リセット以外の方法で復旧できるのであれば該方法も復旧処理に含まれる。構成例図3は、マイコン100のハードウェア構成図の一例を示す。マイコン100は主にワンチップのSOCやLSIであるが、CPU等が別チップになっているマイコン100など実装形態はどのような状態でもよい。また、このマイコン100はECUに搭載されるので、一部の機能をマイコン100でなくECUの基板上に配置することもできる。なお、ECUには、マイコン100の他、センサの信号を受け付ける入力チャネル及びそのドライバ、マイコン100の監視IC、電源IC等が搭載される。マイコン100は、メインバス9に接続されたCPU11、ROM12、INTC14、RAM15、及び、DMAC16、並びに、周辺バス8に接続されたTimer16以下、区別する場合Timer1、Timer0というを有する。I/Oブリッジ17は、メインバス9及び周辺バス8に接続されており、I/Oブリッジ17にはADC以下、区別する場合ADC0、ADC1という及びCANコントローラ19以下、符号は省略するが接続されている。一般に周辺機器という場合には、CPU11、ROM12及びRAM15以外の回路は全て周辺機器である。しかし、機能の提供にはCPU11とアプリも必要とされる。したがって、なんらかの機能が提供できないとは、CPU11がアプリを実行できないこと、アプリが使用する周辺機器が使用できないこと、のいずれも対象となる。このため、リセット対象にはVCPU0,1も含まれることが好ましいROM12及びRAM15は含まない。これに本実施例ではアプリが単体で利用することが多い、Timer0、Timer1、ADC0,ADC1及びCANコントローラを加え、VCPU0,1と共に周辺機器とする。当然ながら、マイコンによってはこれら以外に周辺機器がある場合もある。CPU11は、ハードウェアマルチスレッドHMT型のCPUである。HMTのCPUが仮想的に実現するCPUを仮想CPUと呼ぶ場合があり図ではVVirtualCPUと記載した。HMTは、複数のアプリを擬似的に並行処理することで、外部からは、複数のVCPUが存在するように見える実行環境である。具体的には、複数の命令バッファ、複数の命令デコーダ、複数のレジスタファイル、等をクロック毎に切り換えて使用することで、1つの演算ユニット複数あってもよいを共有して、複数の仮想的なCPUを実現する。1クロックでHTを切り換えることができるので、アプリの切り替え時のオーバヘッドはほぼ無視できる。図ではVCPU0及びVCPU1を有するが、3つ以上のVCPUを動作させることも可能である。なお、VCPU0、1はそれぞれローカルRAM0,1を作業メモリに使用するが、実際には1つのローカルRAMを共有してもよい。本実施例ではVCPUを例に説明するが、マルチコア型のCPU11で各コアが各アプリを実行する場合も、本実施形態に好適に適用できる。ROM12はフラッシュメモリなどの不揮発メモリであり、CPU11が実行するプログラムや静的なデータを記憶している。プログラムには少なくともアプリA、アプリB、及び、故障診断ソフトが含まれている。この他、OSやデバイスドライバが記憶されていてもよい。Timer1及びTimer0は、例えばVCPU0又はVCPU1が設定した値をカウントしてVCPU0又はVCPU1実際にはINTC14に割り込みすることで、VCPU0又はVCPU1に通知する。通知によりVCPU0又はVCPU1が定期的にアプリA、アプリB、又は、アプリA、Bそれぞれに付随するアイドルタスクを実行することを可能にする。また、Timer1及びTimer0はWDTウォッチドッグタイマとして機能することもできる。この場合、Timer1及びTimer0は所定値以上までカウントアップすると、INTC14、不図示のリセット回路、又は、他のマイコンへの通知などを行う。INTC14はIRQやその他の割り込み端子を介して周辺機器から入力された割り込み要求を、周辺機器の優先順位に基づき調停してVCPU0又はVCPU1に通知する。これによりVCPU0又はVCPU1は、割り込みした周辺機器に応じて決まった処理を実行する。RAM15は、CPU11がプログラムを実行するための作業領域である。CPU11はメモリバスを介してROMまたはプログラムをSDRAMに移動して実行する場合はSDRAM12からプログラムを読み込み、また、必要であればデータバスを介してRAM15からデータを読み出しプログラムを実行する。DMAC16は、CPU11からの指示によりRAM15からI/Oブリッジ17を介して周辺機器にデータを送信し、周辺機器から割り込みされたCPU11から指示を受けて、I/Oブリッジ17を介して周辺機器からデータを受け取り、RAM15に書き込む。I/Oブリッジ17は、マルチプレクサ又はブリッジ回路であり、チェネル毎にADC0、ADC1、及び、CANコントローラとそれぞれ接続されており、これらの周辺機器とデータを送受信する。また、メインバス9と周辺バス8との間のバス本数と周波数の違いを吸収して相互にデータを受け渡す。図4は、アプリと周辺機器の関係を示す図の一例である。VCPU0はアプリAを実行し、VCPU1はアプリBを実行している。アプリAは重要度が高、アプリBは低であるとする。この重要度はフェールクラスとして統合前に定義されている。重要度は相対的なものなので、このマイコン以外に搭載されたアプリには、アプリAより重要度が高いアプリもあり得るし、アプリBよりも重要度が低いアプリもあり得る。なお、VCPU1がアプリAを実行し、VCPU0がアプリBを実行してもよい。機能Aは、VCPU0がアプリAを実行し、アプリAがTimer0、ADC0、及び、CANコントローラを使用することで提供される。以下、これらを機能Aに必要な周辺機器という。機能BはVCPU1がアプリBを実行し、アプリBがTimer1、ADC1、及び、CANコントローラを使用することで提供される。以下、これらを機能Bに必要な周辺機器という。このように、CANコントローラはアプリA、Bの両方から使用される共有リソースである。したがって、アプリAは機能Aの提供のためTimer0、ADC0、及び、CANコントローラをリセットする権限を有すべきであるし、アプリBは機能Bの提供のためTimer1、ADC1、及び、CANコントローラをリセットする権限を有すべきである。しかしながら、本実施例では、アプリAのみにCANコントローラをリセットする権限を与えることで、機能Bに起因して重要度の高いアプリAが提供されなくなることを防止している。アプリ毎にリセット可能な周辺機器の情報は例えばROM12に記憶されており、マイコン100の起動時に、CPU11がマイコン100内の初期化や初期定数を設定するための各種の初期設定を行う際に、ROM12から読み出し復旧処理許可フラグ20に設定する。復旧処理許可フラグ20は、CPU11からアクセス可能な記憶装置に記憶されていればよいが、例えばCPU11のレジスタに記憶されているとする。図5aは復旧処理許可フラグ20を模式的に示す図の一例である。周辺機器毎に、アプリA、アプリBそれぞれがリセットすることを許可されている周辺機器が登録されている。1が許可されていることを、0が許可されていないことをそれぞれ示す。復旧処理許可フラグ20に示すようにCANコントローラは共有リソースだがアプリAにのみリセットが許可されている。図5bは各アプリに必要な機器が登録された機器管理テーブル21の一例を示す図である。図5bにおいて、アプリに対し1となっている機器は該アプリにとって必要な機器である。機器管理テーブル21は復旧処理許可フラグ20とほぼ同様になるが、機器管理テーブル21はアプリがリセットできない機器でも使用する機器であれば1となる点で異なっている。図5aとbを比較すると、アプリBがCANコントローラを使用するため、アプリBはCANコントローラを必要とする1設定になっている。また、機器管理テーブル21により、カラム方向に1が複数個登録された機器は共有リソースであることがわかる。これまで説明したようにCANコントローラは共有リソースであることがわかる。図5bでは説明のため、CANコントローラがアプリA、B機能A,Bに共有されていることを明記した。機器管理テーブル21も、CPU11からアクセス可能な記憶装置に記憶されていればよい。図6は、アプリA、B及び故障診断部30の機能ブロック図の一例を示す。まず、アプリA及びアプリBは故障検出部31a、31bを有する。VCPU0がアプリAを実行している際に何らかの不具合が生じれば、機能Aに必要な機器に故障が生じたことが検出される。具体的には、アプリAが周辺機器Timer0、ADC0、及び、CANコントローラにアクセス要求してもタイムアウトするような場合、アプリAの故障検出部31aは機能Aに必要な周辺機器の故障を検出する。また、アプリAがWDTを定期的にリセットしなかったためにWDTがオーバーフローすると、WDTはCPU11に割り込みするので、故障検出部31aはアプリA又はVCPU0に何らかの不具合が生じたことを検出できる。この他、故障検出部31aはアプリAのアイドル時間を利用して、能動的に周辺機器の状態を監視することで、故障を検出することができる。すなわち、故障検出部31aは適当な処理を周辺機器に要求しその処理結果を基準値と比較する、又は、周辺機器にセルフチェックを要求しそのチェック結果を取得することで、故障を検出する。アプリBの故障検出部31bについても同様である。また、VCPU0がアプリAを、VCPU1がアプリBを実行していない状態でも、定期的にセルフチェックを行う周辺機器も存在する。このような周辺機器では、異常が認められるとCPU11に割り込みしたり診断結果をフラグなどで保持するので、故障検出部31a又は31bが周辺機器の故障を検出できる。故障検出部31a、31bは、故障を検出すると故障診断部30を呼び出す。故障診断部30は、機器判定部32、復旧処理部33、復旧回数カウント部34、及び、フェールセーフ部35を有する。なお、図では故障診断部30がアプリA、Bとは別に記載されているが、アプリA及びBの機能として実装されていてもよい。機器判定部32は、復旧処理許可フラグ20を参照してリセットする周辺機器を判定する。まず、アプリAVCPU0から呼び出された場合、機器判定部32は復旧処理許可フラグ20を参照してVCPU0及びローカルRAM0、Timer0、ADC0及びCANコントローラをリセットすると判定する。アプリBVCPU1から呼び出された場合、VCPU1及びローカルRAM1、Timer1及びADC1をリセットすると判定する。復旧処理部33は、機器判定部32がリセットすると判定した周辺機器をリセットし、また、リセットにより復旧したか否かを判定する。リセット方法は例えば、各機器のRST端子をLレベル又はHレベルにするなど機器毎に予め定められている。これにより各周辺機器例えば、VCPU0、Timer0、ADC0及びCANコントローラのレジスタが初期化され、また、ローカルRAMが初期化されるゼロが書き込まれる。なお、アプリA,BがローカルRAMでなく共有のRAMを使用する場合、アプリAの専用領域アドレス範囲、アプリBの専用領域、及び、データの受け渡しに使用する領域が、定まっているので、復旧処理部33はアプリAの専用領域又はアプリBの専用領域のみを初期化する。復旧回数カウント部34は、周辺機器のリセットの回数をカウントする。この回数が所定値以上になると、リセットでは周辺機器の復旧が困難であると判定される。フェールセーフ部35は、復旧が困難な場合に、復旧が困難な周辺機器についてフェールセーフ処理を行う。フェールセーフ処理は、例えば、復旧が困難な周辺機器の分離又は置換である。例えば、置換は、復旧が困難な周辺機器と同等の周辺機器が複数存在する場合に有効である。フェールセーフ部35は復旧が困難な周辺機器の代わりに同等の周辺機器を使用可能にする。例えば、CANコントローラの復旧が困難な場合、該CANコントローラが使用できないように使用禁止のフラグを立て、例えば別のCANコントローラやFlexRayコントローラを有効にするフラグを立てる。また、分離は、復旧が困難な周辺機器と同等の周辺機器が他に存在しない場合に有効である。フェールセーフ部35は復旧が困難な周辺機器がアイドルタスクにだけ使用されるような場合、該周辺機器を使用禁止する。例えば、タイマの復旧が困難であり、タイマはアイドルタスクだけが使用するのであれば、アプリA、Bのいずれも使用できないように該タイマのステータスに使用禁止のフラグを立てるなどする。動作手順図7~9は、マイコン100が故障診断する手順を示すフローチャート図の一例を示す。図7aは機能Aの故障が検出された場合の故障診断手順を、図7bは機能Bの故障が検出された場合の故障診断手順を、それぞれ示す。上記のとおり、機能A又は機能Bのどちらが先に故障するかは定まっていないので、図7aとbのどちらが先に実行されるかも定まっていない。また、CANコントローラがアプリA又はアプリBと関係なく自らの不具合を検出した場合、周辺機器はリセットが許可されたアプリを呼び出すことが好ましいが、リセットが許可されていないアプリが呼び出されてもいずれ不具合のある周辺機器をリセット可能なアプリが呼び出される。図7aの手順は、アプリA又はVCPU0、Timer0、ADC0、及び、CANコントローラに何らかの不具合が生じたことが検出されるとスタートする。まず、故障検出部31aは、アプリAの実行中、又は、周辺機器からの通知により故障を検出するS10。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。故障検出部31aは、故障診断部30を呼び出して復旧処理Aを開始させるS20。以下、故障診断部30は、後述する復旧処理Aを実行する。CPU11が有するVCPUが2つのみの場合、故障診断部30はアプリBを実行中のVCPU1のコンテキストを退避して、故障診断部30を起動するアプリBよりも故障診断の方が優先度が高いものとする。CPU11が有するVCPUが3つ以上の場合、故障検出部31aはCPU11やOSを利用して第3のVCPUを実現させ故障診断部30を起動させる。これらにより、VCPU1又は第3のVCPUはVCPU0をリセットすることができる。復旧処理Aが終了すると故障診断部30は後述する診断結果に基づき機能Aに必要な周辺機器に致命的故障が生じたか否かを判定するS30。診断結果の種類は、復旧完了、周辺機器の識別情報と置換又は分離の別、又は、周辺機器の識別情報と致命的故障、のいずれかである。診断結果が復旧完了又は周辺機器の識別情報と置換又は分離の別、であればアプリAに復帰できると判定する。機能Aに必要な周辺機器の致命的故障でない場合S30のNo、故障診断部30はVCPU0にアプリAの処理を再開させるS40。具体的には、故障診断部30はVCPU0にコンテキストを復帰させ、VCPU0にアプリAを再開させる。機能Aに必要な周辺機器の診断結果が致命的故障の場合S30のYes、故障診断部30は機能Aの復旧が困難であると判定するS50。この場合、故障診断部30は機能Aの重要度に応じて運転者に警告する。例えば、運転者にすぐに運転中止を要求する等である。図7bの手順は、アプリB又はVCPU1、Timer1、ADC1、及び、CANコントローラに何らかの不具合が生じたことが検出されるとスタートする。まず、故障検出部31bは、アプリBの実行中、又は、周辺機器からの通知により故障を検出するS110。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。故障検出部31bは、故障診断部30を呼び出して復旧処理Bを開始させるS120。以下、故障診断部30は、後述する復旧処理Bを実行する。アプリAはアプリBより重要度が高いので、第3のVCPUが故障診断部30を実行することが好ましい。復旧処理Bが終了すると故障診断部30は診断結果に基づき機能Bに必要な周辺機器に致命的故障が生じたか否かを判定するS30。機能Bに必要な周辺機器の致命的故障でない場合S130のNo、故障診断部30はVCPU1にアプリBの処理を再開させるS140。機能Bに必要な周辺機器の診断結果が致命的故障の場合S130のYes、故障診断部30は機能Bの復旧が困難であると判定するS150。この場合、故障診断部30は機能Bの重要度に応じて運転者に警告する。例えば、警告ランプを点灯する等である。図8は、復旧処理Aの手順を示すフローチャート図の一例である。復旧処理Aは第3のVCPUが実行するとして説明する。まず、復旧処理部33がマイコン100の全ての周辺機器にリセット命令を発行するS201。このリセット命令は復旧処理許可フラグ20にて許可されていない周辺機器に対しては無効になる。次に、機器判定部32は復旧処理許可フラグ20を参照し、リセット可能な周辺機器を特定し、復旧処理部33がそれらの周辺機器をリセットするS202。復旧処理Aにおいてリセット可能な周辺機器は、Timer0、ADC0、CANコントローラ、及び、VCPU0である。次に、復旧回数カウント部34はリセット信号を出力した回数を周辺機器毎にカウントするS203。こうすることで、周辺機器を何回リセットしたかを判定できる。復旧処理部33は、機器管理テーブル21を参照して機能Aに必要な周辺機器が復旧したか否かを判定するS204。復旧の有無の判定は、故障したか否かの判定と同様なので、復旧処理部33は周辺機器が応答するか否か、セルフチェック結果に異常があるか否かに等により復旧したか否かを判定する。なお、復帰処理Aでは、リセットされた周辺機器と復旧したか否かが判定される周辺機器が同じである。機能Aに必要な全ての周辺機器が復旧した場合S204のYes、復旧処理部33は、機能Aが復旧したという診断結果を記憶し、図8の処理を終了する。機能Aに必要な周辺機器が1つでも復旧しない場合S204のNo、復旧処理部33は、リセット回数がX回目以上か否かを判定するS205。X回は復旧に十分なリセット回数であり通常は1回のリセットで復旧するとしてよい、例えば3~5回である。この回数に達していない場合、復旧処理部33はステップS201のリセット命令の発行以降を繰り返す。リセットの回数がX回目以上の場合、復旧処理部33は復旧しない周辺機器は復旧できないと判定し、フェールセーフ部35に復旧しない周辺機器の識別情報を通知する。これにより、フェールセーフ部35は、復旧しない周辺機器についてフェールセーフ処理を行うS206。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能なら分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図7aのステップS30に戻る。図9は、復旧処理Bの手順を示すフローチャート図の一例である。復旧処理Bは第3のVCPUが実行するとして説明する。復旧処理Bは機能Aよりも重要度の低い機能Bの復旧処理であるため、復旧処理部33がアプリAに復旧処理を依頼する点に特徴がある。まず、復旧処理部33がマイコン100の全ての周辺機器にリセット命令を発行するS1201。このリセット命令は復旧処理許可フラグ20にて許可されていない周辺機器に対しては無効になる。次に、機器判定部32は復旧処理許可フラグ20を参照し、リセット可能な周辺機器を特定し、復旧処理部33はそれらの周辺機器をリセットするS1202。復旧処理Bにおいてリセット可能な周辺機器は、Timer1、ADC1及びVCPU1である。次に、復旧回数カウント部34はリセット信号を出力した回数を周辺機器毎にカウントするS1203。こうすることで、周辺機器が何回リセットしたかを判定できる。復旧処理部33は、機器管理テーブル21を参照し機能Bに必要な周辺機器が復旧したか否かを判定するS1204。復旧の有無の判定方法は図8と同じである。しかしながら、復旧処理Bではリセットされた周辺機器と復旧したか否かが判定される周辺機器が同じにならない。復旧処理Bでは、リセットされてないCANコントローラについても復旧したか否かを判定する。機能Bに必要な全ての周辺機器が復旧した場合S1204のYes、復旧処理部33は、機能Bが復旧したという診断結果を記憶し、図9の処理を終了する。機能Bに必要な周辺機器が1つでも復旧しない場合S204のNo、復旧処理部33は、リセット回数がX回目以上か否かを判定するS1205。リセットの回数がX回目以上の場合、リセットしたTimer1又はADC1のいずれかに不具合が生じている場合と、リセットしていないCANコントローラに不具合が生じている場合がある。そこで、復旧処理部33はアプリAに通知するS1206。すなわち、復旧処理部33は図5bの機器管理テーブル21を参照し、アプリBとアプリAの共有リソースを特定する。そして、復旧処理許可フラグ20を参照して、アプリBがリセットできない共有リソースCANコントローラをリセットできるアプリAを特定する。図9の手順は機能Bに必要な周辺機器が故障した場合に実行されるので、VCPU0はアプリAを実行中である。アプリAは、重要度の高い処理なので、まずはその処理を優先的に実行するが、アプリAのメインタスクが終了した後などに通知を受け取り、アプリAの故障検出部31aが共有リソースを使用するS1207。つまり、使用することで共有リソースであるCANコントローラが故障しているか否かを判定する。よって、ステップS1207ではCANコントローラの故障判定を行ってもよい。故障検出部31aは共有リソースが故障しているか否かを判定するS1208。故障している場合S1208のYes、アプリAの故障検出部31aは、故障診断部30を呼び出して復旧処理Aを開始させるS1209。この場合は、CANコントローラに不具合があることが疑われる。以下、故障診断部30は、復旧処理Aを実行する。復旧処理Aの内容は図8と同じである。これにより、機能Bに必要な周辺機器が故障した場合でも、アプリBではなくアプリAが処理に支障がない状況で、機能Bで必要な周辺機器をリセットすることができる。なお、処理は図7bのS130に戻る。共有リソースが故障していない場合S1208のNo、復旧処理部33は復旧しない周辺機器は復旧できないと判定し、フェールセーフ部35に復旧しない周辺機器の識別情報を通知する。この場合、Timer1又はADC1のいずれかに復旧しない不具合が生じている可能性が高い。これにより、フェールセーフ部35は、復旧しない周辺機器についてフェールセーフ処理を行うS1210。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能な場合は分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図7bのステップS130に戻る。以上説明したように、本実施例のマイコン100は、マイコン100の全体をリセットすることなく機能毎に周辺機器をリセットし、重要度の低い機能は重要度の高い機能にリセットを要求する。このため、重要度の低い機能が重要度の高い機能の提供を阻害することなく、重要度の低い機能と高い機能が共有する周辺機器を早期に復旧させることができる。特に、重要度の高いアプリAの動作頻度がアプリBよりも少ないため、共有リソースの使用頻度が少ない場合、アプリBが先に共有リソースの不具合を検出する状況が多くなる。この場合、本実施例では、アプリAがアプリBから通知を受けて共有リソースをリセットするので、アプリBが共有リソースをリセットしなくても早期に機能Bを提供可能になる。なお、本実施例において機能Aと機能Bの重要度が同等の場合、共有リソースはアプリA又はアプリBの故障検出部が故障を検出したタイミングでリセットされる。しかしながら、この場合でも、復旧処理許可フラグ20により共有リソースのリセットをアプリA又はアプリBの一方にのみ許可することも可能である。本実施例では1つのマイコン100が3つ以上の機能を提供する場合について説明する。図10は、アプリと周辺機器の関係を示す図の一例である。図10において図4と同一部の説明は省略する。図10ではVCPUを囲む線は省略したがVCPUも周辺機器である。本実施例では、VCPU0はアプリAを実行し、VCPU1はアプリBを実行し、VCPU2はアプリCを実行している。アプリAは重要度が高、アプリBは中、アプリCは低であるとする。機能Aは、VCPU0がアプリAを実行し、アプリAがTimer0、ADC0、及び、CANコントローラを使用することで提供される。機能BはVCPU1がアプリBを実行し、アプリBがTimer1、ADC1、及び、CANコントローラを使用することで提供される。機能CはVCPU2がアプリCを実行し、アプリCがADC1,Timer2、ADC2、及び、CANコントローラを使用することで提供される。このように、CANコントローラはアプリA、B、Cによって使用される共有リソースであり、ADC1はアプリB、Cによって使用される共有リソースである。3つ以上の重要度の異なるアプリが周辺機器を共有する場合、リセットする権限は相対的に重要度が高い機能を提供するアプリにのみ認められる。すなわち、CANコントローラを共有するアプリA、B、Cのうち最も重要度が高いアプリAのみがCANコントローラをリセットできる。ADC1を共有するアプリB、Cのうち最も重要度が高いアプリBのみがADC1をリセットできる。したがって、復旧処理許可フラグ20は以下のようになる。図11aは本実施例の復旧処理許可フラグ20の一例を示す図である。図5aと比較すると周辺機器毎に、アプリA~Cそれぞれがリセットすることを許可されている周辺機器が登録されている。この復旧処理許可フラグ20に示すようにCANコントローラはアプリAにのみリセットが許可され、ADC1はアプリBにのみリセットが許可されている。図11bは本実施例の機器管理テーブル21の一例を示す図である。この図から、ADC1はアプリB,Cに共有され、CANコントローラはアプリA,B,Cにより共有されていることが分かる。実施例図11abから明らかなように、アプリCは、アプリCが他のアプリA,Bと共有するADC1、CANコントローラをリセットできない。このため、アプリCはADC1のリセットが可能なアプリBに、CANコントローラのリセットが可能なアプリAに、それぞれ復旧処理A,Bを要求する必要がある。すなわち、アプリCは例えば順番にアプリAに復旧処理ACANコントローラのリセットを依頼し、アプリBに復旧処理BADC1のリセットを依頼する。なお、機能ブロック図は省略するが、機能ブロック図はアプリCが故障検出部を有する以外は実施例1と同様である。動作手順本実施例の場合、復旧処理が開始されるのは、機能Aに必要な周辺機器が故障した場合、機能Bに必要な周辺機器が故障した場合、及び、機能Cに必要な周辺機器が故障した場合の3つの場合がある。しかしながら、処理手順は、重要度の低い機能に必要な周辺機器が故障した場合は、重要度のより高い機能を提供するアプリにリセットを要求するという点で実施例1と同様である。すなわち、アプリBに必要な周辺機器が故障した場合、復旧処理部33はアプリAに通知し必要であれば復旧処理Aを実行する。したがって、この場合は実施例1と同様である。図12は機能Cの故障が検出された場合のマイコン100の処理手順の一例を示す。図12の手順は、アプリC又はVCPU2、ADC1、ADC2、Timer2又はCANコントローラに何らかの不具合が生じたことが検出されるとスタートする。まず、故障検出部は、アプリCの実行中、又は、周辺機器からの通知により故障を検出するS210。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。故障検出部は、故障診断部30を呼び出して復旧処理Cを開始させるS220。以下、故障診断部30は、復旧処理Cを実行する。復旧処理Cが終了すると故障診断部30は診断結果に基づき機能Cに必要な周辺機器に致命的故障が生じたか否かを判定するS230。機能Cに必要な周辺機器の致命的故障でない場合S230のNo、故障診断部30はVCPU2にアプリCの処理を再開させるS240。機能Cに必要な周辺機器の診断結果が致命的故障の場合S230のYes、故障診断部30は機能Cの復旧が困難であると判定するS250。この場合、故障診断部30は機能Cの重要度に応じて運転者に警告する。例えば、診断結果を記録しておき、IGオフ→オン後に再度、同じ診断結果がえられると警告ランプを点灯する等である。図13は、復旧処理Cの手順を示すフローチャート図の一例である。復旧処理Cは機能A、Bよりも重要度の低い機能Cの復旧処理であるため、復旧処理部33がアプリB及びアプリAに復旧処理を依頼する点に特徴がある。なお、復旧処理Cは第4のVCPUが実行するとして説明する。概略を説明する。アプリCに必要な周辺機器が故障した場合、復旧処理部33はアプリBに通知し必要であれば復旧処理Bを実行するか図13のS2209又はアプリAを呼び出す図13のS2210。復旧処理Bの中で復旧処理部33はアプリAに通知し必要であれば復旧処理Aを実行する。アプリAが呼び出された場合、呼び出されたアプリAは必要であれば復旧処理Aを実行する図13のS2213。なお、CANコントローラがアプリA~Cと関係なく自らの不具合を検出した場合、例えば、リセット許可のあるアプリAに復旧処理を要求すればよい。ADC1についても同様である。以下、詳細に説明する。まず、復旧処理部33がマイコン100の全ての周辺機器にリセット命令を発行するS2201。このリセット命令は復旧処理許可フラグ20にて許可されていない周辺機器に対しては無効になる。次に、機器判定部32は復旧処理許可フラグ20を参照し、リセット可能な周辺機器を特定するS2202。復旧処理Cにおいてリセット可能な周辺機器は、Timer2、ADC2及びVCPU2である。次に、復旧回数カウント部34はリセット信号を出力した回数を周辺機器毎にカウントするS2203。こうすることで、リセットした回数をカウントできる。復旧処理部33は、機器管理テーブル21を参照して機能Cに必要な周辺機器毎が復旧したか否かを判定するS2204。復旧の有無の判定方法は図8と同じである。しかしながら、復旧処理Cではリセットされた周辺機器と復旧したか否かが判定される周辺機器が同じにならない。復旧処理Cでは、リセットされてないCANコントローラ及びADC1についても復旧したか否かを判定する。機能Cに必要な全ての周辺機器が復旧した場合S2204のYes、復旧処理部33は、機能Cが復旧したという診断結果を記憶し、図13の処理を終了する。機能Cに必要な周辺機器が1つでも復旧しない場合S2204のNo、復旧処理部33は、リセット回数がX回目以上か否かを判定するS2205。リセットの回数がX回目以上の場合、リセットしたTimer2又はADC2のいずれかに不具合が生じている場合と、リセットしていないCANコントローラ又はADC1に不具合が生じている場合がある。そこで、復旧処理部33はアプリBに共有リソースを通知するS2206。復旧処理部33は図11bの機器管理テーブル21を参照し、周辺機器毎にアプリCと周辺機器を共有するアプリを特定する。この場合は、ADC1についてアプリBを、CANコントローラについてアプリAとBを特定できる。そして、復旧処理部33は、復旧処理許可フラグ20を参照してアプリCではリセットできない共有リソースADC1、CANコントローラをリセットできるアプリを決定する。この場合、ADC1についてアプリBが、CANコントローラについてアプリAが特定される。このように、通知対象のアプリとしてはアプリAとアプリBが特定されるが、どちらを先に選択しても、機能Cに必要な周辺機器が復旧しない場合は次に別のアプリが呼び出されるので、アプリAとBのどちらを選択してもよい。S2206ではアプリBが選択されたものとする。アプリBは、機能Cより優先度の高い機能Bを提供しているので、まずはその処理を優先的に実行するが、アプリBのメインタスクが終了した後などに通知を受け取り、アプリBの故障検出部31bが共有リソースを使用するS2207。つまり、使用することで共有リソースであるADC1が故障しているか否かを判定する。よって、ステップS2207ではADC1の故障判定を行ってもよい。アプリBの故障検出部31bは共有リソースのADC1が故障しているか否かを判定するS2208。故障している場合S2208のYes、アプリBの故障検出部31bは、故障診断部30を呼び出して復旧処理Bを開始させるS2209。以下、故障診断部30は、復旧処理Bを実行する。復旧処理Bの内容は図9と同じである。復旧処理Bでは、ADC1とTimer1をリセットし、ADC1、Timer1及びCANコントローラの復旧の有無を判定する。そして、CANコントローラが復旧していない場合は復旧処理Aが実行されるので、CANコントローラについてもリセットされる。よって、機能Cに必要な周辺機器が故障した場合でも、アプリCではなくアプリB、Aが処理に支障がない状況で機能Cで必要な周辺機器をリセットすることができる。一方、共有リソースのADC1が故障していない場合S2208のNo、復旧処理部33はアプリAに通知するS2210。すなわち、アプリBの故障判定部31bはADC1に不具合がないことを復旧処理部33に通知するので、復旧処理部33は次のアプリであるアプリAに共有リソースを通知する。アプリAは、機能Cより優先度の高い機能Aを提供しているので、まずはその処理を優先的に実行するが、アプリAのメインタスクが終了した後などに通知を受け取り、アプリAの故障検出部31aが共有リソースを使用するS2211。つまり、使用することで共有リソースであるCANコントローラが故障しているか否かを判定する。よって、ステップS2211ではCANコントローラの故障判定を行ってもよい。アプリAの故障検出部31aは共有リソースのCANコントローラが故障しているか否かを判定するS2212。故障している場合S2212のYes、アプリAの故障検出部31aは、故障診断部30を呼び出して復旧処理Aを開始させるS2213。以下、故障診断部30は、復旧処理Aを実行する。復旧処理Aの内容は図8と同じである。復旧処理Aでは、Timer0、ADC0及びCANコントローラをリセットし、Timer0、ADC0及びCANコントローラの復旧の有無を判定する。よって、機能Cに必要な周辺機器のうち、復旧処理Bでは故障が見つからなかったCANコントローラを復旧させることができる。共有リソースのCANコントローラが故障していない場合S2212のNo、ADC1及びCANコントローラのどちらも不具合がないことになるので、機能Cに必要なTimer2又はADC2に復旧困難な不具合が生じていることが分かる。復旧処理部33はアプリAの故障検出部31aから故障していないという通知を受け取り、フェールセーフ部35に復旧しない周辺機器の識別情報を通知する。これにより、フェールセーフ部35は、復旧しない周辺機器についてフェールセーフ処理を行うS2214。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能な場合は分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図12のステップS230に戻る。以上説明したように、本実施例のマイコン100は、3つ以上の機能が統合された場合も、故障を検出したアプリがより優先度の高いアプリに復旧を依頼するので、優先度の高い処理を停止することなく周辺機器を復旧できる。また、重要度の低いアプリが複数の共有リソースを共有していても、共有リソースをリセット可能なアプリに順番に復旧処理を依頼するので、優先度の高い処理を停止することなく確実に周辺機器を復旧できる。なお、図10において重要度の組合せが高、中、低としたが、例えば高、高、中低のような組合せでも同様に処理できる。重要度が中低のアプリケーションは、必要な周辺機器をリセットできる重要度が高のアプリを必要に応じて複数回呼び出せばよい。したがって、4つ以上のアプリの重要度の組合せが高、中、低、極低や高、中、中、低等の場合も同様に処理できる。"