(57)【要約】【課題】各機能に必要な機器の故障が検出された場合に他の機能の提供を阻害せずに機器を復旧できるマイコンを提供すること。【解決手段】複数のアプリと１つ以上の機器とが協働することで複数の機能を提供可能なマイコン１００において、機器毎に復旧処理が許可されたアプリが登録された復旧処理許可フラグ２０と、アプリと協働する機器が登録された機器テーブル２１と、機器の不具合を検出する不具合検出手段３１と、不具合機器を使用する第１のアプリと協働する機器であって第１のアプリに復旧処理が許可された機器を、復旧処理許可フラグにより特定する機器特定手段３２と、復旧処理を行っても前記不具合機器が復旧しない場合、前記第１のアプリケーションが他のアプリと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第２のアプリを呼び出して共有機器の故障判定を要求する復旧処理手段３３と、を有することを特徴とする。【選択図】図２
2012226483.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションと１つ以上の機器とが協働することで複数の機能を提供可能なマイコンにおいて、
機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、
アプリケーションと協働する機器が登録された機器テーブルと、
機器の不具合を検出する不具合検出手段と、
不具合機器を使用する第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定する機器特定手段と、
特定された機器に復旧処理を行い、復旧処理を行っても前記不具合機器が復旧しない場合、前記第１のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第２のアプリケーションを呼び出して共有機器の故障判定を要求する復旧処理手段と、
を有することを特徴とするマイコン。
【請求項２】
前記第２のアプリケーションが共有機器が故障していると判定した場合、前記復旧処理手段は、該共有機器に復旧処理を行う、
ことを特徴とする請求項１記載のマイコン。
【請求項３】
前記第２のアプリケーションが共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、
ことを特徴とする請求項１又は２記載のマイコン。
【請求項４】
前記復旧処理手段が前記共有機器に復旧処理を行っても、該共有機器が復旧しない場合、前記復旧処理手段は、前記共有機器に復旧困難な故障が生じていると判定する、
ことを特徴とする請求項２記載のマイコン。
【請求項５】
前記第１のアプリケーションが他のアプリケーションと共有する共有機器が複数ある場合において、
前記復旧処理手段が前記共有機器に復旧処理を行っても、該共有機器が復旧しない場合、前記復旧処理手段は、前記第１のアプリケーションが他のアプリケーションと共有する第２の共有機器を前記機器テーブルにより特定し、該第２の共有機器の復旧処理が許可された第３のアプリケーションを呼び出して第２の共有機器の故障判定を要求する、
ことを特徴とする請求項２記載のマイコン。
【請求項６】
前記第３のアプリケーションが第２の共有機器が故障していると判定した場合、前記復旧処理手段は、該第２の共有機器に復旧処理を行う、
ことを特徴とする請求項５記載のマイコン。
【請求項７】
前記第３のアプリケーションが第２の共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、
ことを特徴とする請求項５記載のマイコン。
【請求項８】
前記第２のアプリケーションが共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第１のアプリケーションが他のアプリケーションと共有する第２の共有機器を前記機器テーブルにより特定し、該第２の共有機器の復旧処理が許可された第３のアプリケーションを呼び出して第２の共有機器の故障判定を要求する、
ことを特徴とする請求項５記載のマイコン。
【請求項９】
前記第３のアプリケーションが第２の共有機器が故障していないと判定した場合、前記復旧処理手段は、前記第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器に復旧困難な故障が生じていると判定する、
ことを特徴とする請求項８記載のマイコン。
【請求項１０】
機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、
アプリケーションと協働する機器が登録された機器テーブルと、を有し、
複数のアプリケーションと１つ以上の機器とが協働することで複数の機能を提供可能なマイコンの故障判定方法において、
不具合検出手段が、機器の不具合を検出するステップと、
機器特定手段が、不具合機器を使用する第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定するステップと、
復旧処理手段が、特定された機器に復旧処理を行っても前記不具合機器が復旧しない場合、前記第１のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第２のアプリケーションを呼び出して共有機器の故障判定を要求するステップと、
を有することを特徴とする故障判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数のアプリを搭載したマイコンに関し、特に、アプリ毎に復旧処理が可能なマイコンに関する。  
【背景技術】
【０００２】
車両には車載装置の制御用のマイコンが搭載されているが、マイコンに搭載されるハード及びソフトは益々高度化・複雑化する傾向にある。また、国際的な安全規格としてIEC61580／ISO26262が策定されており、マイコンに故障検出や復旧処理の仕組みが要請されるようになってきた。
【０００３】
マイコンの故障検出や復旧処理については従来から様々な技術が考案されている（例えば、特許文献１参照。）。特許文献１には、部品の死活確認をハードウェア手法によって検出し、遅延なくソフトウェア的な資源割当手段に通知し、異常のある部品を異常のない部品に切り替える物理資源制御管理システムが開示されている。この物理資源制御管理システムによればハード的な仮想空間を維持したまま高速な復旧が可能になるとしている。
【０００４】
また、従来、デュアルコアロックステップのようなリダンダンシ（冗長）回路が、複数の実行結果をマッチングして故障を検出し、故障が検出されるとマイコンをリセットすることで復旧する手法が知られている。これにより、ソフトエラーやノイズ等で発生した誤動作時に復旧することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１０７８９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、車載されるマイコン（又は、ＥＣＵ：Electronic  Control  Unit）の数が増大してきたことから、複数のＥＣＵの機能を統合して１つのＥＣＵに統合する試みが行われている。統合ＥＣＵには複数の機能が搭載されるため、統合ＥＣＵの複数の機能の重要度が同じとは限らない状況が生じうる。例えば、１つの統合ＥＣＵが、重要度が低い機能Ｂとより重要度の高い機能Ａを有するような場合が生じる。機能ＡはアプリＡと関係が強く、アプリＡが周辺機器を使用して提供される機能であり、機能ＢはアプリＢと関係が強く、アプリＢが周辺機器を使用して提供される機能である。
【０００７】
このような統合ＥＣＵにおいて、機能Ｂに故障が生じた場合（すなわち、アプリＢが使用する周辺機器の故障、又は、アプリＢの動作の異常）を検出した場合に、統合ＥＣＵに搭載されたマイコン自体をリセットすると、再起動するまでの間に重要度の高い機能Ａが提供されないという不都合が生じる。
【０００８】
この不都合を回避するため、機能に関係するアプリ（ＣＰＵ）や周辺機器のみをリセットすることが考えられる。
【０００９】
図１はこのような不都合の回避を説明する図の一例である。図１では上記の回路として、ＣＰＵと周辺機器を示した。機能ＡはＣＰＵ０がアプリＡを実行し周辺回路０，１を使用することで、機能ＢはＣＰＵ１がアプリＢを実行し周辺回路１，２を使用することで、それぞれ提供されている。例えば、機能Ｂに必要な周辺機器２に不具合が生じた場合、統合ＥＣＵが周辺機器２やＣＰＵ１をリセットすれば機能Ａは影響を受けない。よって、機能に関係するアプリや周辺機器のみをリセットすることで、重要度の高い機能Ａが提供されないという不都合を回避できる場合がある。
【００１０】
しかし、機能Ｂに必要な周辺機器１に不具合が生じた場合、統合ＥＣＵが周辺機器１をリセットすれば機能Ａが影響を受けてしまう。このように共有リソースについては、機能に関係するアプリや周辺機器のみをリセットするだけでは不都合を回避できない。すなわち、統合ＥＣＵにおいて重要度の異なる機能が統合された場合、共有されるリソースを安易にリセットすると、重要度の高い機能Ａが共有リソースを使用できなくなり、上記の不都合が生じてしまう。
【００１１】
そこで、共有リソース以外（図１の周辺機器０，２）については、各アプリＡ，Ｂがリセットの是非を管理し、共有リソース（図１の周辺機器１）については、重要度の最も高いアプリＡのみがリセット可能に設定しておくことが考えられる。しかし、このようにすると、重要度の低いアプリＢが周辺機器１の故障を検出した場合に、アプリＢは周辺機器１をリセットできないため、機能Ｂの復旧ができないという不都合が残る。
【００１２】
本発明は、上記課題に鑑み、重要度の異なる複数のアプリが統合されたマイコンにおいて、各機能に必要な機器の故障が検出された場合に他の機能の提供を阻害せずに機器を復旧できるマイコンを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、複数のアプリケーションと１つ以上の機器とが協働することで複数の機能を提供可能なマイコンにおいて、機器毎に復旧処理が許可されたアプリケーションが登録された復旧処理許可フラグと、アプリケーションと協働する機器が登録された機器テーブルと、機器の不具合を検出する不具合検出手段と、不具合機器を使用する第１のアプリケーションと協働する機器であって第１のアプリケーションに復旧処理が許可された機器を、前記復旧処理許可フラグにより特定する機器特定手段と、特定された機器に復旧処理を行い、復旧処理を行っても前記不具合機器が復旧しない場合、前記第１のアプリケーションが他のアプリケーションと共有する共有機器を前記機器テーブルにより特定し、該共有機器の復旧処理が許可された第２のアプリケーションを呼び出して共有機器の故障判定を要求する復旧処理手段と、を有することを特徴とするマイコン。
【発明の効果】
【００１４】
重要度の異なる複数のアプリが統合されたマイコンにおいて、各機能に必要な機器の故障が検出された場合に他の機能の提供を阻害せずに機器を復旧できるマイコンを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】従来において不都合の回避を説明する図の一例である。
【図２】マイコンにおける周辺機器の復旧を説明する図の一例である。
【図３】マイコン１００のハードウェア構成図の一例である。
【図４】アプリと周辺機器の関係を示す図の一例である。
【図５】復旧処理許可フラグを模式的に示す図の一例である。
【図６】アプリＡ、Ｂ及び故障診断部の機能ブロック図の一例である。
【図７】機能Ａの故障が検出された場合の故障診断手順及び機能Ｂの故障が検出された場合の故障診断手順を示す図の一例である。
【図８】復旧処理Ａの手順を示すフローチャート図の一例である。
【図９】復旧処理Ｂの手順を示すフローチャート図の一例である。
【図１０】アプリと周辺機器の関係を示す図の一例である（実施例２）。
【図１１】復旧処理許可フラグの一例を示す図である（実施例２）。
【図１２】機能Ｃの故障が検出された場合の故障診断手順の示す図の一例である。
【図１３】復旧処理Ｃの手順を示すフローチャート図の一例である。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【００１７】
〔概略〕
図２は、マイコンにおける周辺機器の復旧を説明する図の一例である。
ＶＣＰＵ０がアプリケーションＡを、ＶＣＰＵ１がアプリケーションＢをそれぞれ実行している。機能Ａ、機能Ｂは次のように提供され、機能Ａの方が機能Ｂよりも重要度が高いものとする。機能とアプリケーション（以下、アプリという場合がある）は対応しているのでアプリＡの方がアプリＢよりも重要度が高いといってもよい。
機能Ａ：アプリＡが周辺機器０，１を使用して提供する。
機能Ｂ：アプリＢが周辺機器１，２を使用して提供する。
【００１８】
したがって、周辺機器１は共有リソースである。また、ＶＣＰＵ０，１が参照できる場所の復旧処理許可フラグに、周辺機器０〜２毎に周辺機器のリセットが許可されたアプリが登録されている。一例として、共有リソースである周辺機器１は、重要度の高いアプリＡのみがリセットできるように設定されている。
【００１９】
このような構成において、機能Ｂに必要な周辺機器に不具合が生じると、アプリＢは復旧処理許可フラグを参照し、リセットが許可されている周辺機器２だけをリセットする。これにより、機能Ｂが提供可能になれば復旧処理は終了である。
【００２０】
リセットしても機能Ｂが提供可能とならない場合、機能Ｂが復旧できないのは周辺機器１に故障が生じたためであることが疑われる。このため、アプリＢはアプリＡに故障の検出を通知する。アプリＡは周辺機器１をリセットすることが許可されているので、アプリＡは重要度の高い自己の処理の優先度を保ちながら周辺機器１をリセットする。これにより、周辺機器１が復旧すれば、機能Ｂの提供が可能になる。
【００２１】
したがって、本実施形態のマイコンは、重要度の異なる機能が統合された状態において、統合された機能のうち重要度の低い機能に必要な周辺機器が故障しても、マイコン全体をリセットしないので重要度の高い機能が提供されなくなることがない。また、重要度の低い機能の提供中に、重要度の高い機能が共通に使用する周辺機器が故障した場合（以下、機能の故障という場合がある）、重要度の低い機能が重要度の高い機能にリセットを要求するので、重要度の高い機能が該周辺機器を復旧させることができる。したがって、重要度の低い機能が使用できない状態が長時間継続することも防止できる。
【００２２】
なお、以下では、復旧処理をリセットという。復旧処理は周辺機器を使用できる状態に戻す処理をいうので、リセット以外の方法で復旧できるのであれば該方法も復旧処理に含まれる。
【実施例１】
【００２３】
〔構成例〕
図３は、マイコン１００のハードウェア構成図の一例を示す。マイコン１００は主にワンチップのＳＯＣやＬＳＩであるが、ＣＰＵ等が別チップになっているマイコン１００など実装形態はどのような状態でもよい。また、このマイコン１００はＥＣＵに搭載されるので、一部の機能をマイコン１００でなくＥＣＵの基板上に配置することもできる。なお、ＥＣＵには、マイコン１００の他、センサの信号を受け付ける入力チャネル及びそのドライバ、マイコン１００の監視ＩＣ、電源ＩＣ等が搭載される。
【００２４】
マイコン１００は、メインバス９に接続されたＣＰＵ１１、ＲＯＭ１２、ＩＮＴＣ１４、ＲＡＭ１５、及び、ＤＭＡＣ１６、並びに、周辺バス８に接続されたＴｉｍｅｒ１６（以下、区別する場合Timer1、Timer0という）を有する。Ｉ／Ｏブリッジ１７は、メインバス９及び周辺バス８に接続されており、Ｉ／Ｏブリッジ１７にはＡＤＣ（以下、区別する場合ADC0、ADC1という）及びＣＡＮコントローラ１９（以下、符号は省略する）が接続されている。
【００２５】
一般に周辺機器という場合には、ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１５以外の回路は全て周辺機器である。しかし、機能の提供にはＣＰＵ１１とアプリも必要とされる。したがって、なんらかの機能が提供できないとは、ＣＰＵ１１がアプリを実行できないこと、アプリが使用する周辺機器が使用できないこと、のいずれも対象となる。このため、リセット対象にはＶＣＰＵ０，１も含まれることが好ましい（ＲＯＭ１２及びＲＡＭ１５は含まない）。これに本実施例ではアプリが単体で利用することが多い、Timer0、Timer1、ADC0，ADC1及びＣＡＮコントローラを加え、ＶＣＰＵ０，１と共に周辺機器とする。当然ながら、マイコンによってはこれら以外に周辺機器がある場合もある。
【００２６】
ＣＰＵ１１は、ハードウェアマルチスレッド（ＨＭＴ）型のＣＰＵである。ＨＭＴのＣＰＵが仮想的に実現するＣＰＵを仮想ＣＰＵと呼ぶ場合があり図ではＶ（Virtual）CPUと記載した。ＨＭＴは、複数のアプリを擬似的に並行処理することで、外部からは、複数のＶＣＰＵが存在するように見える実行環境である。具体的には、複数の命令バッファ、複数の命令デコーダ、複数のレジスタファイル、等をクロック毎に切り換えて使用することで、１つの演算ユニット（複数あってもよい）を共有して、複数の仮想的なＣＰＵを実現する。１クロックでＨＴを切り換えることができるので、アプリの切り替え時のオーバヘッドはほぼ無視できる。
【００２７】
図ではＶＣＰＵ０及びＶＣＰＵ１を有するが、３つ以上のＶＣＰＵを動作させることも可能である。なお、ＶＣＰＵ０、１はそれぞれローカルＲＡＭ０，１を作業メモリに使用するが、実際には１つのローカルＲＡＭを共有してもよい。
【００２８】
本実施例ではＶＣＰＵを例に説明するが、マルチコア型のＣＰＵ１１で各コアが各アプリを実行する場合も、本実施形態に好適に適用できる。
【００２９】
ＲＯＭ１２はフラッシュメモリなどの不揮発メモリであり、ＣＰＵ１１が実行するプログラムや静的なデータを記憶している。プログラムには少なくともアプリＡ、アプリＢ、及び、故障診断ソフトが含まれている。この他、ＯＳやデバイスドライバが記憶されていてもよい。
【００３０】
Timer1及びTimer0は、例えばＶＣＰＵ０又はＶＣＰＵ１が設定した値をカウントしてＶＣＰＵ０又はＶＣＰＵ１（実際にはＩＮＴＣ１４）に割り込みすることで、ＶＣＰＵ０又はＶＣＰＵ１に通知する。通知によりＶＣＰＵ０又はＶＣＰＵ１が定期的にアプリＡ、アプリＢ、又は、アプリＡ、Ｂそれぞれに付随するアイドルタスクを実行することを可能にする。また、Timer1及びTimer0はＷＤＴ（ウォッチドッグタイマ）として機能することもできる。この場合、Timer1及びTimer0は所定値以上までカウントアップすると、ＩＮＴＣ１４、不図示のリセット回路、又は、他のマイコンへの通知などを行う。
【００３１】
ＩＮＴＣ１４はＩＲＱやその他の割り込み端子を介して周辺機器から入力された割り込み要求を、周辺機器の優先順位に基づき調停してＶＣＰＵ０又はＶＣＰＵ１に通知する。これによりＶＣＰＵ０又はＶＣＰＵ１は、割り込みした周辺機器に応じて決まった処理を実行する。
【００３２】
ＲＡＭ１５は、ＣＰＵ１１がプログラムを実行するための作業領域である。ＣＰＵ１１はメモリバスを介してＲＯＭ（またはプログラムをＳＤＲＡＭに移動して実行する場合はＳＤＲＡＭ）１２からプログラムを読み込み、また、必要であればデータバスを介してＲＡＭ１５からデータを読み出しプログラムを実行する。
【００３３】
ＤＭＡＣ１６は、ＣＰＵ１１からの指示によりＲＡＭ１５からＩ／Ｏブリッジ１７を介して周辺機器にデータを送信し、周辺機器から割り込みされたＣＰＵ１１から指示を受けて、Ｉ／Ｏブリッジ１７を介して周辺機器からデータを受け取り、ＲＡＭ１５に書き込む。
【００３４】
Ｉ／Ｏブリッジ１７は、マルチプレクサ又はブリッジ回路であり、チェネル毎にADC0、ADC1、及び、ＣＡＮコントローラとそれぞれ接続されており、これらの周辺機器とデータを送受信する。また、メインバス９と周辺バス８との間のバス本数と周波数の違いを吸収して相互にデータを受け渡す。
【００３５】
図４は、アプリと周辺機器の関係を示す図の一例である。ＶＣＰＵ０はアプリＡを実行し、ＶＣＰＵ１はアプリＢを実行している。アプリＡは重要度が高、アプリＢは低であるとする。この重要度はフェールクラスとして統合前に定義されている。重要度は相対的なものなので、このマイコン以外に搭載されたアプリには、アプリＡより重要度が高いアプリもあり得るし、アプリＢよりも重要度が低いアプリもあり得る。なお、ＶＣＰＵ１がアプリＡを実行し、ＶＣＰＵ０がアプリＢを実行してもよい。
【００３６】
機能Ａは、ＶＣＰＵ０がアプリＡを実行し、アプリＡがTimer0、ADC0、及び、ＣＡＮコントローラを使用することで提供される。以下、これらを機能Ａに必要な周辺機器という。機能ＢはＶＣＰＵ１がアプリＢを実行し、アプリＢがTimer1、ADC1、及び、ＣＡＮコントローラを使用することで提供される。以下、これらを機能Ｂに必要な周辺機器という。このように、ＣＡＮコントローラはアプリＡ、Ｂの両方から使用される共有リソースである。
【００３７】
したがって、アプリＡは機能Ａの提供のためTimer0、ADC0、及び、ＣＡＮコントローラをリセットする権限を有すべきであるし、アプリＢは機能Ｂの提供のためTimer1、ADC1、及び、ＣＡＮコントローラをリセットする権限を有すべきである。しかしながら、本実施例では、アプリＡのみにＣＡＮコントローラをリセットする権限を与えることで、機能Ｂに起因して重要度の高いアプリＡが提供されなくなることを防止している。
【００３８】
アプリ毎にリセット可能な周辺機器の情報は例えばＲＯＭ１２に記憶されており、マイコン１００の起動時に、ＣＰＵ１１がマイコン１００内の初期化や初期定数を設定するための各種の初期設定を行う際に、ＲＯＭ１２から読み出し復旧処理許可フラグ２０に設定する。復旧処理許可フラグ２０は、ＣＰＵ１１からアクセス可能な記憶装置に記憶されていればよいが、例えばＣＰＵ１１のレジスタに記憶されているとする。
【００３９】
図５（ａ）は復旧処理許可フラグ２０を模式的に示す図の一例である。周辺機器毎に、アプリＡ、アプリＢそれぞれがリセットすることを許可されている周辺機器が登録されている。“１”が許可されていることを、“０”が許可されていないことをそれぞれ示す。復旧処理許可フラグ２０に示すようにＣＡＮコントローラは共有リソースだがアプリＡにのみリセットが許可されている。
【００４０】
図５（ｂ）は各アプリに必要な機器が登録された機器管理テーブル２１の一例を示す図である。図５（ｂ）において、アプリに対し“１”となっている機器は該アプリにとって必要な機器である。機器管理テーブル２１は復旧処理許可フラグ２０とほぼ同様になるが、機器管理テーブル２１はアプリがリセットできない機器でも使用する機器であれば“１”となる点で異なっている。図５（ａ）と（ｂ）を比較すると、アプリＢがＣＡＮコントローラを使用するため、アプリＢはＣＡＮコントローラを必要とする（“１”）設定になっている。
【００４１】
また、機器管理テーブル２１により、カラム方向に“１”が複数個登録された機器は共有リソースであることがわかる。これまで説明したようにＣＡＮコントローラは共有リソースであることがわかる。図５（ｂ）では説明のため、ＣＡＮコントローラがアプリＡ、Ｂ（機能Ａ，Ｂ）に共有されていることを明記した。機器管理テーブル２１も、ＣＰＵ１１からアクセス可能な記憶装置に記憶されていればよい。
【００４２】
図６は、アプリＡ、Ｂ及び故障診断部３０の機能ブロック図の一例を示す。まず、アプリＡ及びアプリＢは故障検出部３１ａ、３１ｂを有する。ＶＣＰＵ０がアプリＡを実行している際に何らかの不具合が生じれば、機能Ａに必要な機器に故障が生じたことが検出される。具体的には、アプリＡが周辺機器（Timer0、ADC0、及び、ＣＡＮコントローラ）にアクセス要求してもタイムアウトするような場合、アプリＡの故障検出部３１ａは機能Ａに必要な周辺機器の故障を検出する。また、アプリＡがＷＤＴを定期的にリセットしなかったためにＷＤＴがオーバーフローすると、ＷＤＴはＣＰＵ１１に割り込みするので、故障検出部３１ａはアプリＡ（又はＶＣＰＵ０）に何らかの不具合が生じたことを検出できる。
【００４３】
この他、故障検出部３１ａはアプリＡのアイドル時間を利用して、能動的に周辺機器の状態を監視することで、故障を検出することができる。すなわち、故障検出部３１ａは適当な処理を周辺機器に要求しその処理結果を基準値と比較する、又は、周辺機器にセルフチェックを要求しそのチェック結果を取得することで、故障を検出する。アプリＢの故障検出部３１ｂについても同様である。
【００４４】
また、ＶＣＰＵ０がアプリＡを、ＶＣＰＵ１がアプリＢを実行していない状態でも、定期的にセルフチェックを行う周辺機器も存在する。このような周辺機器では、異常が認められるとＣＰＵ１１に割り込みしたり診断結果をフラグなどで保持するので、故障検出部３１ａ又は３１ｂが周辺機器の故障を検出できる。
【００４５】
故障検出部３１ａ、３１ｂは、故障を検出すると故障診断部３０を呼び出す。故障診断部３０は、機器判定部３２、復旧処理部３３、復旧回数カウント部３４、及び、フェールセーフ部３５を有する。なお、図では故障診断部３０がアプリＡ、Ｂとは別に記載されているが、アプリＡ及びＢの機能として実装されていてもよい。
【００４６】
機器判定部３２は、復旧処理許可フラグ２０を参照してリセットする周辺機器を判定する。まず、アプリＡ（ＶＣＰＵ０）から呼び出された場合、機器判定部３２は復旧処理許可フラグ２０を参照してＶＣＰＵ０（及びローカルＲＡＭ０）、Timer0、ADC0及びＣＡＮコントローラをリセットすると判定する。アプリＢ（ＶＣＰＵ１）から呼び出された場合、ＶＣＰＵ１（及びローカルＲＡＭ１）、Timer1及びADC1をリセットすると判定する。
【００４７】
復旧処理部３３は、機器判定部３２がリセットすると判定した周辺機器をリセットし、また、リセットにより復旧したか否かを判定する。リセット方法は例えば、各機器のＲＳＴ端子をＬレベル（又はＨレベル）にするなど機器毎に予め定められている。これにより各周辺機器（例えば、ＶＣＰＵ０、Timer0、ADC0及びＣＡＮコントローラ）のレジスタが初期化され、また、ローカルＲＡＭが初期化される（ゼロが書き込まれる）。
【００４８】
なお、アプリＡ，ＢがローカルＲＡＭでなく共有のＲＡＭを使用する場合、アプリＡの専用領域（アドレス範囲）、アプリＢの専用領域、及び、データの受け渡しに使用する領域が、定まっているので、復旧処理部３３はアプリＡの専用領域又はアプリＢの専用領域のみを初期化する。
【００４９】
復旧回数カウント部３４は、周辺機器のリセットの回数をカウントする。この回数が所定値以上になると、リセットでは周辺機器の復旧が困難であると判定される。フェールセーフ部３５は、復旧が困難な場合に、復旧が困難な周辺機器についてフェールセーフ処理を行う。フェールセーフ処理は、例えば、復旧が困難な周辺機器の分離又は置換である。
【００５０】
例えば、置換は、復旧が困難な周辺機器と同等の周辺機器が複数存在する場合に有効である。フェールセーフ部３５は復旧が困難な周辺機器の代わりに同等の周辺機器を使用可能にする。例えば、ＣＡＮコントローラの復旧が困難な場合、該ＣＡＮコントローラが使用できないように使用禁止のフラグを立て、例えば別のＣＡＮコントローラやＦｌｅｘＲａｙコントローラを有効にするフラグを立てる。
【００５１】
また、分離は、復旧が困難な周辺機器と同等の周辺機器が他に存在しない場合に有効である。フェールセーフ部３５は復旧が困難な周辺機器がアイドルタスクにだけ使用されるような場合、該周辺機器を使用禁止する。例えば、タイマの復旧が困難であり、タイマはアイドルタスクだけが使用するのであれば、アプリＡ、Ｂのいずれも使用できないように該タイマのステータスに使用禁止のフラグを立てるなどする。
【００５２】
〔動作手順〕
図７〜９は、マイコン１００が故障診断する手順を示すフローチャート図の一例を示す。図７（ａ）は機能Ａの故障が検出された場合の故障診断手順を、図７（ｂ）は機能Ｂの故障が検出された場合の故障診断手順を、それぞれ示す。上記のとおり、機能Ａ又は機能Ｂのどちらが先に故障するかは定まっていないので、図７（ａ）と（ｂ）のどちらが先に実行されるかも定まっていない。
【００５３】
また、ＣＡＮコントローラがアプリＡ又はアプリＢと関係なく自らの不具合を検出した場合、周辺機器はリセットが許可されたアプリを呼び出すことが好ましいが、リセットが許可されていないアプリが呼び出されてもいずれ不具合のある周辺機器をリセット可能なアプリが呼び出される。
【００５４】
図７（ａ）の手順は、アプリＡ（又はＶＣＰＵ０）、Timer0、ADC0、及び、ＣＡＮコントローラに何らかの不具合が生じたことが検出されるとスタートする。
【００５５】
まず、故障検出部３１ａは、アプリＡの実行中、又は、周辺機器からの通知により故障を検出する（Ｓ１０）。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。
【００５６】
故障検出部３１ａは、故障診断部３０を呼び出して復旧処理Ａを開始させる（Ｓ２０）。以下、故障診断部３０は、後述する復旧処理Ａを実行する。ＣＰＵ１１が有するＶＣＰＵが２つのみの場合、故障診断部３０はアプリＢを実行中のＶＣＰＵ１のコンテキストを退避して、故障診断部３０を起動する（アプリＢよりも故障診断の方が優先度が高いものとする）。ＣＰＵ１１が有するＶＣＰＵが３つ以上の場合、故障検出部３１ａはＣＰＵ１１やＯＳを利用して第３のＶＣＰＵを実現させ故障診断部３０を起動させる。これらにより、ＶＣＰＵ１又は第３のＶＣＰＵはＶＣＰＵ０をリセットすることができる。
【００５７】
復旧処理Ａが終了すると故障診断部３０は後述する診断結果に基づき機能Ａに必要な周辺機器に致命的故障が生じたか否かを判定する（Ｓ３０）。診断結果の種類は、復旧完了、周辺機器の識別情報と置換又は分離の別、又は、周辺機器の識別情報と致命的故障、のいずれかである。診断結果が復旧完了又は周辺機器の識別情報と置換又は分離の別、であればアプリＡに復帰できると判定する。
【００５８】
機能Ａに必要な周辺機器の致命的故障でない場合（Ｓ３０のＮｏ）、故障診断部３０はＶＣＰＵ０にアプリＡの処理を再開させる（Ｓ４０）。具体的には、故障診断部３０はＶＣＰＵ０にコンテキストを復帰させ、ＶＣＰＵ０にアプリＡを再開させる。
【００５９】
機能Ａに必要な周辺機器の診断結果が致命的故障の場合（Ｓ３０のＹｅｓ）、故障診断部３０は機能Ａの復旧が困難であると判定する（Ｓ５０）。この場合、故障診断部３０は機能Ａの重要度に応じて運転者に警告する。例えば、運転者にすぐに運転中止を要求する等である。
【００６０】
図７（ｂ）の手順は、アプリＢ（又はＶＣＰＵ１）、Timer1、ADC1、及び、ＣＡＮコントローラに何らかの不具合が生じたことが検出されるとスタートする。
【００６１】
まず、故障検出部３１ｂは、アプリＢの実行中、又は、周辺機器からの通知により故障を検出する（Ｓ１１０）。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。
【００６２】
故障検出部３１ｂは、故障診断部３０を呼び出して復旧処理Ｂを開始させる（Ｓ１２０）。以下、故障診断部３０は、後述する復旧処理Ｂを実行する。アプリＡはアプリＢより重要度が高いので、第３のＶＣＰＵが故障診断部３０を実行することが好ましい。
【００６３】
復旧処理Ｂが終了すると故障診断部３０は診断結果に基づき機能Ｂに必要な周辺機器に致命的故障が生じたか否かを判定する（Ｓ３０）。
【００６４】
機能Ｂに必要な周辺機器の致命的故障でない場合（Ｓ１３０のＮｏ）、故障診断部３０はＶＣＰＵ１にアプリＢの処理を再開させる（Ｓ１４０）。
【００６５】
機能Ｂに必要な周辺機器の診断結果が致命的故障の場合（Ｓ１３０のＹｅｓ）、故障診断部３０は機能Ｂの復旧が困難であると判定する（Ｓ１５０）。この場合、故障診断部３０は機能Ｂの重要度に応じて運転者に警告する。例えば、警告ランプを点灯する等である。
【００６６】
図８は、復旧処理Ａの手順を示すフローチャート図の一例である。復旧処理Ａは第３のＶＣＰＵが実行するとして説明する。まず、復旧処理部３３がマイコン１００の全ての周辺機器にリセット命令を発行する（Ｓ２０１）。このリセット命令は復旧処理許可フラグ２０にて許可されていない周辺機器に対しては無効になる。
【００６７】
次に、機器判定部３２は復旧処理許可フラグ２０を参照し、リセット可能な周辺機器を特定し、復旧処理部３３がそれらの周辺機器をリセットする（Ｓ２０２）。復旧処理Ａにおいてリセット可能な周辺機器は、Timer0、ADC0、ＣＡＮコントローラ、及び、ＶＣＰＵ０である。
【００６８】
次に、復旧回数カウント部３４はリセット信号を出力した回数を周辺機器毎にカウントする（Ｓ２０３）。こうすることで、周辺機器を何回リセットしたかを判定できる。
【００６９】
復旧処理部３３は、機器管理テーブル２１を参照して機能Ａに必要な周辺機器が復旧したか否かを判定する（Ｓ２０４）。復旧の有無の判定は、故障したか否かの判定と同様なので、復旧処理部３３は周辺機器が応答するか否か、セルフチェック結果に異常があるか否かに等により復旧したか否かを判定する。なお、復帰処理Ａでは、リセットされた周辺機器と復旧したか否かが判定される周辺機器が同じである。
【００７０】
機能Ａに必要な全ての周辺機器が復旧した場合（Ｓ２０４のＹｅｓ）、復旧処理部３３は、機能Ａが復旧したという診断結果を記憶し、図８の処理を終了する。
【００７１】
機能Ａに必要な周辺機器が１つでも復旧しない場合（Ｓ２０４のＮｏ）、復旧処理部３３は、リセット回数がＸ回目以上か否かを判定する（Ｓ２０５）。Ｘ回は復旧に十分なリセット回数であり（通常は１回のリセットで復旧するとしてよい）、例えば３〜５回である。この回数に達していない場合、復旧処理部３３はステップＳ２０１のリセット命令の発行以降を繰り返す。
【００７２】
リセットの回数がＸ回目以上の場合、復旧処理部３３は復旧しない周辺機器は復旧できないと判定し、フェールセーフ部３５に復旧しない周辺機器の識別情報を通知する。これにより、フェールセーフ部３５は、復旧しない周辺機器についてフェールセーフ処理を行う（Ｓ２０６）。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能なら分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図７（ａ）のステップＳ３０に戻る。
【００７３】
図９は、復旧処理Ｂの手順を示すフローチャート図の一例である。復旧処理Ｂは第３のＶＣＰＵが実行するとして説明する。復旧処理Ｂは機能Ａよりも重要度の低い機能Ｂの復旧処理であるため、復旧処理部３３がアプリＡに復旧処理を依頼する点に特徴がある。
【００７４】
まず、復旧処理部３３がマイコン１００の全ての周辺機器にリセット命令を発行する（Ｓ１２０１）。このリセット命令は復旧処理許可フラグ２０にて許可されていない周辺機器に対しては無効になる。
【００７５】
次に、機器判定部３２は復旧処理許可フラグ２０を参照し、リセット可能な周辺機器を特定し、復旧処理部３３はそれらの周辺機器をリセットする（Ｓ１２０２）。復旧処理Ｂにおいてリセット可能な周辺機器は、Timer1、ADC1及びＶＣＰＵ１である。
【００７６】
次に、復旧回数カウント部３４はリセット信号を出力した回数を周辺機器毎にカウントする（Ｓ１２０３）。こうすることで、周辺機器が何回リセットしたかを判定できる。
【００７７】
復旧処理部３３は、機器管理テーブル２１を参照し機能Ｂに必要な周辺機器が復旧したか否かを判定する（Ｓ１２０４）。復旧の有無の判定方法は図８と同じである。しかしながら、復旧処理Ｂではリセットされた周辺機器と復旧したか否かが判定される周辺機器が同じにならない。復旧処理Ｂでは、リセットされてないＣＡＮコントローラについても復旧したか否かを判定する。
【００７８】
機能Ｂに必要な全ての周辺機器が復旧した場合（Ｓ１２０４のＹｅｓ）、復旧処理部３３は、機能Ｂが復旧したという診断結果を記憶し、図９の処理を終了する。
【００７９】
機能Ｂに必要な周辺機器が１つでも復旧しない場合（Ｓ２０４のＮｏ）、復旧処理部３３は、リセット回数がＸ回目以上か否かを判定する（Ｓ１２０５）。
【００８０】
リセットの回数がＸ回目以上の場合、リセットしたTimer1又はADC1のいずれかに不具合が生じている場合と、リセットしていないＣＡＮコントローラに不具合が生じている場合がある。
【００８１】
そこで、復旧処理部３３はアプリＡに通知する（Ｓ１２０６）。すなわち、復旧処理部３３は図５（ｂ）の機器管理テーブル２１を参照し、アプリＢとアプリＡの共有リソースを特定する。そして、復旧処理許可フラグ２０を参照して、アプリＢがリセットできない共有リソース（ＣＡＮコントローラ）をリセットできるアプリＡを特定する。
【００８２】
図９の手順は機能Ｂに必要な周辺機器が故障した場合に実行されるので、ＶＣＰＵ０はアプリＡを実行中である。アプリＡは、重要度の高い処理なので、まずはその処理を優先的に実行するが、アプリＡのメインタスクが終了した後などに通知を受け取り、アプリＡの故障検出部３１ａが共有リソースを使用する（Ｓ１２０７）。つまり、使用することで共有リソースであるＣＡＮコントローラが故障しているか否かを判定する。よって、ステップＳ１２０７ではＣＡＮコントローラの故障判定を行ってもよい。
【００８３】
故障検出部３１ａは共有リソースが故障しているか否かを判定する（Ｓ１２０８）。故障している場合（Ｓ１２０８のＹｅｓ）、アプリＡの故障検出部３１ａは、故障診断部３０を呼び出して復旧処理Ａを開始させる（Ｓ１２０９）。この場合は、ＣＡＮコントローラに不具合があることが疑われる。以下、故障診断部３０は、復旧処理Ａを実行する。復旧処理Ａの内容は図８と同じである。これにより、機能Ｂに必要な周辺機器が故障した場合でも、アプリＢではなくアプリＡが処理に支障がない状況で、機能Ｂで必要な周辺機器をリセットすることができる。なお、処理は図7（ｂ）のＳ１３０に戻る。
【００８４】
共有リソースが故障していない場合（Ｓ１２０８のＮｏ）、復旧処理部３３は復旧しない周辺機器は復旧できないと判定し、フェールセーフ部３５に復旧しない周辺機器の識別情報を通知する。この場合、Timer1又はADC1のいずれかに復旧しない不具合が生じている可能性が高い。これにより、フェールセーフ部３５は、復旧しない周辺機器についてフェールセーフ処理を行う（Ｓ１２１０）。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能な場合は分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図７（ｂ）のステップＳ１３０に戻る。
【００８５】
以上説明したように、本実施例のマイコン１００は、マイコン１００の全体をリセットすることなく機能毎に周辺機器をリセットし、重要度の低い機能は重要度の高い機能にリセットを要求する。このため、重要度の低い機能が重要度の高い機能の提供を阻害することなく、重要度の低い機能と高い機能が共有する周辺機器を早期に復旧させることができる。
【００８６】
特に、重要度の高いアプリＡの動作頻度がアプリＢよりも少ないため、共有リソースの使用頻度が少ない場合、アプリＢが先に共有リソースの不具合を検出する状況が多くなる。この場合、本実施例では、アプリＡがアプリＢから通知を受けて共有リソースをリセットするので、アプリＢが共有リソースをリセットしなくても早期に機能Ｂを提供可能になる。
【００８７】
なお、本実施例において機能Ａと機能Ｂの重要度が同等の場合、共有リソースはアプリＡ又はアプリＢの故障検出部が故障を検出したタイミングでリセットされる。しかしながら、この場合でも、復旧処理許可フラグ２０により共有リソースのリセットをアプリＡ又はアプリＢの一方にのみ許可することも可能である。
【実施例２】
【００８８】
本実施例では１つのマイコン１００が３つ以上の機能を提供する場合について説明する。
図１０は、アプリと周辺機器の関係を示す図の一例である。図１０において図４と同一部の説明は省略する。図１０ではＶＣＰＵを囲む線は省略したがＶＣＰＵも周辺機器である。
【００８９】
本実施例では、ＶＣＰＵ０はアプリＡを実行し、ＶＣＰＵ１はアプリＢを実行し、ＶＣＰＵ２はアプリＣを実行している。アプリＡは重要度が高、アプリＢは中、アプリＣは低であるとする。機能Ａは、ＶＣＰＵ０がアプリＡを実行し、アプリＡがTimer0、ADC0、及び、ＣＡＮコントローラを使用することで提供される。機能ＢはＶＣＰＵ１がアプリＢを実行し、アプリＢがTimer1、ADC1、及び、ＣＡＮコントローラを使用することで提供される。機能ＣはＶＣＰＵ２がアプリＣを実行し、アプリＣがADC1，Timer2、ADC2、及び、ＣＡＮコントローラを使用することで提供される。
【００９０】
このように、ＣＡＮコントローラはアプリＡ、Ｂ、Ｃによって使用される共有リソースであり、ADC1はアプリＢ、Cによって使用される共有リソースである。
【００９１】
３つ以上の重要度の異なるアプリが周辺機器を共有する場合、リセットする権限は相対的に重要度が高い機能を提供するアプリにのみ認められる。すなわち、ＣＡＮコントローラを共有するアプリＡ、Ｂ、Ｃのうち最も重要度が高いアプリＡのみがＣＡＮコントローラをリセットできる。ADC1を共有するアプリＢ、Ｃのうち最も重要度が高いアプリＢのみがADC1をリセットできる。したがって、復旧処理許可フラグ２０は以下のようになる。
【００９２】
図１１（ａ）は本実施例の復旧処理許可フラグ２０の一例を示す図である。図５（ａ）と比較すると周辺機器毎に、アプリＡ〜Ｃそれぞれがリセットすることを許可されている周辺機器が登録されている。この復旧処理許可フラグ２０に示すようにＣＡＮコントローラはアプリＡにのみリセットが許可され、ADC1はアプリＢにのみリセットが許可されている。
【００９３】
図１１（ｂ）は本実施例の機器管理テーブル２１の一例を示す図である。この図から、ADC1はアプリＢ，Ｃに共有され、ＣＡＮコントローラはアプリＡ，Ｂ，Ｃにより共有されていることが分かる。
【００９４】
実施例図１１（ａ）（ｂ）から明らかなように、アプリＣは、アプリＣが他のアプリＡ，Ｂと共有するADC1、ＣＡＮコントローラをリセットできない。このため、アプリＣはADC1のリセットが可能なアプリＢに、ＣＡＮコントローラのリセットが可能なアプリＡに、それぞれ復旧処理Ａ，Ｂを要求する必要がある。すなわち、アプリＣは例えば順番にアプリＡに復旧処理Ａ（ＣＡＮコントローラのリセット）を依頼し、アプリＢに復旧処理Ｂ（ADC1のリセット）を依頼する。
【００９５】
なお、機能ブロック図は省略するが、機能ブロック図はアプリＣが故障検出部を有する以外は実施例１と同様である。
【００９６】
〔動作手順〕
本実施例の場合、復旧処理が開始されるのは、機能Ａに必要な周辺機器が故障した場合、機能Ｂに必要な周辺機器が故障した場合、及び、機能Ｃに必要な周辺機器が故障した場合の３つの場合がある。しかしながら、処理手順は、重要度の低い機能に必要な周辺機器が故障した場合は、重要度のより高い機能を提供するアプリにリセットを要求するという点で実施例１と同様である。すなわち、アプリＢに必要な周辺機器が故障した場合、復旧処理部３３はアプリＡに通知し必要であれば復旧処理Ａを実行する。したがって、この場合は実施例１と同様である。
【００９７】
図１２は機能Ｃの故障が検出された場合のマイコン１００の処理手順の一例を示す。図１２の手順は、アプリＣ（又はＶＣＰＵ２）、ADC1、ADC2、Timer2又はＣＡＮコントローラに何らかの不具合が生じたことが検出されるとスタートする。
【００９８】
まず、故障検出部は、アプリＣの実行中、又は、周辺機器からの通知により故障を検出する（Ｓ２１０）。ここでは故障した周辺機器を特定する必要はないが、不具合のある周辺機器が明らかであればその周辺機器だけリセット対象とすることもできる。
【００９９】
故障検出部は、故障診断部３０を呼び出して復旧処理Ｃを開始させる（Ｓ２２０）。以下、故障診断部３０は、復旧処理Ｃを実行する。
【０１００】
復旧処理Ｃが終了すると故障診断部３０は診断結果に基づき機能Ｃに必要な周辺機器に致命的故障が生じたか否かを判定する（Ｓ２３０）。
【０１０１】
機能Ｃに必要な周辺機器の致命的故障でない場合（Ｓ２３０のＮｏ）、故障診断部３０はＶＣＰＵ２にアプリＣの処理を再開させる（Ｓ２４０）。
【０１０２】
機能Ｃに必要な周辺機器の診断結果が致命的故障の場合（Ｓ２３０のＹｅｓ）、故障診断部３０は機能Ｃの復旧が困難であると判定する（Ｓ２５０）。この場合、故障診断部３０は機能Ｃの重要度に応じて運転者に警告する。例えば、診断結果を記録しておき、ＩＧオフ→オン後に再度、同じ診断結果がえられると警告ランプを点灯する等である。
【０１０３】
図１３は、復旧処理Ｃの手順を示すフローチャート図の一例である。復旧処理Ｃは機能Ａ、Ｂよりも重要度の低い機能Ｃの復旧処理であるため、復旧処理部３３がアプリＢ及びアプリＡに復旧処理を依頼する点に特徴がある。なお、復旧処理Ｃは第４のＶＣＰＵが実行するとして説明する。
【０１０４】
概略を説明する。アプリＣに必要な周辺機器が故障した場合、復旧処理部３３はアプリＢに通知し必要であれば復旧処理Ｂを実行するか（図１３のＳ２２０９）又はアプリＡを呼び出す（図１３のＳ２２１０）。復旧処理Ｂの中で復旧処理部３３はアプリＡに通知し必要であれば復旧処理Ａを実行する。アプリＡが呼び出された場合、呼び出されたアプリＡは必要であれば復旧処理Ａを実行する（図１３のＳ２２１３）。
【０１０５】
なお、ＣＡＮコントローラがアプリＡ〜Ｃと関係なく自らの不具合を検出した場合、例えば、リセット許可のあるアプリＡに復旧処理を要求すればよい。ADC1についても同様である。以下、詳細に説明する。
【０１０６】
まず、復旧処理部３３がマイコン１００の全ての周辺機器にリセット命令を発行する（Ｓ２２０１）。このリセット命令は復旧処理許可フラグ２０にて許可されていない周辺機器に対しては無効になる。
【０１０７】
次に、機器判定部３２は復旧処理許可フラグ２０を参照し、リセット可能な周辺機器を特定する（Ｓ２２０２）。復旧処理Ｃにおいてリセット可能な周辺機器は、Timer2、ADC2及びＶＣＰＵ２である。
【０１０８】
次に、復旧回数カウント部３４はリセット信号を出力した回数を周辺機器毎にカウントする（Ｓ２２０３）。こうすることで、リセットした回数をカウントできる。
【０１０９】
復旧処理部３３は、機器管理テーブル２１を参照して機能Ｃに必要な周辺機器毎が復旧したか否かを判定する（Ｓ２２０４）。復旧の有無の判定方法は図８と同じである。しかしながら、復旧処理Ｃではリセットされた周辺機器と復旧したか否かが判定される周辺機器が同じにならない。復旧処理Ｃでは、リセットされてないＣＡＮコントローラ及びADC1についても復旧したか否かを判定する。
【０１１０】
機能Ｃに必要な全ての周辺機器が復旧した場合（Ｓ２２０４のＹｅｓ）、復旧処理部３３は、機能Ｃが復旧したという診断結果を記憶し、図１３の処理を終了する。
【０１１１】
機能Ｃに必要な周辺機器が１つでも復旧しない場合（Ｓ２２０４のＮｏ）、復旧処理部３３は、リセット回数がＸ回目以上か否かを判定する（Ｓ２２０５）。
【０１１２】
リセットの回数がＸ回目以上の場合、リセットしたTimer2又はADC2のいずれかに不具合が生じている場合と、リセットしていないＣＡＮコントローラ又はADC1に不具合が生じている場合がある。
【０１１３】
そこで、復旧処理部３３はアプリＢに共有リソースを通知する（Ｓ２２０６）。復旧処理部３３は図１１（ｂ）の機器管理テーブル２１を参照し、周辺機器毎にアプリＣと周辺機器を共有するアプリを特定する。この場合は、ADC1についてアプリＢを、ＣＡＮコントローラについてアプリＡとＢを特定できる。そして、復旧処理部３３は、復旧処理許可フラグ２０を参照してアプリＣではリセットできない共有リソース（ADC1、ＣＡＮコントローラ）をリセットできるアプリを決定する。この場合、ADC1についてアプリＢが、ＣＡＮコントローラについてアプリＡが特定される。
【０１１４】
このように、通知対象のアプリとしてはアプリＡとアプリＢが特定されるが、どちらを先に選択しても、機能Ｃに必要な周辺機器が復旧しない場合は次に別のアプリが呼び出されるので、アプリＡとＢのどちらを選択してもよい。Ｓ２２０６ではアプリＢが選択されたものとする。
【０１１５】
アプリＢは、機能Ｃより優先度の高い機能Ｂを提供しているので、まずはその処理を優先的に実行するが、アプリＢのメインタスクが終了した後などに通知を受け取り、アプリＢの故障検出部３１ｂが共有リソースを使用する（Ｓ２２０７）。つまり、使用することで共有リソースであるADC1が故障しているか否かを判定する。よって、ステップＳ２２０７ではADC1の故障判定を行ってもよい。
【０１１６】
アプリＢの故障検出部３１ｂは共有リソースのADC1が故障しているか否かを判定する（Ｓ２２０８）。故障している場合（Ｓ２２０８のＹｅｓ）、アプリＢの故障検出部３１ｂは、故障診断部３０を呼び出して復旧処理Ｂを開始させる（Ｓ２２０９）。以下、故障診断部３０は、復旧処理Ｂを実行する。復旧処理Ｂの内容は図９と同じである。復旧処理Ｂでは、ADC1とTimer1をリセットし、ADC1、Timer1及びＣＡＮコントローラの復旧の有無を判定する。そして、ＣＡＮコントローラが復旧していない場合は復旧処理Ａが実行されるので、ＣＡＮコントローラについてもリセットされる。よって、機能Ｃに必要な周辺機器が故障した場合でも、アプリＣではなくアプリＢ、Ａが処理に支障がない状況で機能Ｃで必要な周辺機器をリセットすることができる。
【０１１７】
一方、共有リソースのADC1が故障していない場合（Ｓ２２０８のＮｏ）、復旧処理部３３はアプリＡに通知する（Ｓ２２１０）。すなわち、アプリＢの故障判定部３１ｂはADC1に不具合がないことを復旧処理部３３に通知するので、復旧処理部３３は次のアプリであるアプリＡに共有リソースを通知する。
【０１１８】
アプリＡは、機能Ｃより優先度の高い機能Ａを提供しているので、まずはその処理を優先的に実行するが、アプリＡのメインタスクが終了した後などに通知を受け取り、アプリＡの故障検出部３１ａが共有リソースを使用する（Ｓ２２１１）。つまり、使用することで共有リソースであるＣＡＮコントローラが故障しているか否かを判定する。よって、ステップＳ２２１１ではＣＡＮコントローラの故障判定を行ってもよい。
【０１１９】
アプリＡの故障検出部３１ａは共有リソースのＣＡＮコントローラが故障しているか否かを判定する（Ｓ２２１２）。故障している場合（Ｓ２２１２のＹｅｓ）、アプリＡの故障検出部３１ａは、故障診断部３０を呼び出して復旧処理Ａを開始させる（Ｓ２２１３）。以下、故障診断部３０は、復旧処理Ａを実行する。復旧処理Ａの内容は図８と同じである。復旧処理Ａでは、Timer0、ADC0及びＣＡＮコントローラをリセットし、Timer0、ADC0及びＣＡＮコントローラの復旧の有無を判定する。よって、機能Ｃに必要な周辺機器のうち、復旧処理Ｂでは故障が見つからなかったＣＡＮコントローラを復旧させることができる。
【０１２０】
共有リソースのＣＡＮコントローラが故障していない場合（Ｓ２２１２のＮｏ）、ADC1及びＣＡＮコントローラのどちらも不具合がないことになるので、機能Ｃに必要なTimer2又はADC2に復旧困難な不具合が生じていることが分かる。復旧処理部３３はアプリＡの故障検出部３１ａから故障していないという通知を受け取り、フェールセーフ部３５に復旧しない周辺機器の識別情報を通知する。これにより、フェールセーフ部３５は、復旧しない周辺機器についてフェールセーフ処理を行う（Ｓ２２１４）。具体的には、置換可能な周辺機器があれば置換し、置換可能な周辺機器がない場合で分離可能な場合は分離する。置換又は分離した場合は、置換又は分離された周辺機器の識別情報と置換又は分離の区別を示す診断結果を記憶する。置換又は分離が困難な周辺機器が故障した場合、致命的故障と判定した診断結果を記憶する。この後、処理は図１２のステップＳ２３０に戻る。
【０１２１】
以上説明したように、本実施例のマイコン１００は、３つ以上の機能が統合された場合も、故障を検出したアプリがより優先度の高いアプリに復旧を依頼するので、優先度の高い処理を停止することなく周辺機器を復旧できる。また、重要度の低いアプリが複数の共有リソースを共有していても、共有リソースをリセット可能なアプリに順番に復旧処理を依頼するので、優先度の高い処理を停止することなく確実に周辺機器を復旧できる。
【０１２２】
なお、図１０において重要度の組合せが「高、中、低」としたが、例えば「高、高、中（低）」のような組合せでも同様に処理できる。重要度が中（低）のアプリケーションは、必要な周辺機器をリセットできる重要度が高のアプリを必要に応じて複数回呼び出せばよい。したがって、４つ以上のアプリの重要度の組合せが「高、中、低、極低」や「高、中、中、低」等の場合も同様に処理できる。
【符号の説明】
【０１２３】
１１    ＣＰＵ
１２    ＲＯＭ
１３    Ｔｉｍｅｒ
１４    ＩＮＴＣ
１５    ＲＡＭ
１６    ＤＭＡＣ
１７    Ｉ／Ｏブリッジ
１８    ＡＤＣ
１９    ＣＡＮコントローラ
２０    復旧処理許可フラグ
２１    機器管理テーブル
１００  マイコン
【図１】
2012226483.tif 000003
【図２】
2012226483.tif 000004
【図３】
2012226483.tif 000005
【図４】
2012226483.tif 000006
【図５】
2012226483.tif 000007
【図６】
2012226483.tif 000008
【図７】
2012226483.tif 000009
【図８】
2012226483.tif 000010
【図９】
2012226483.tif 000011
【図１０】
2012226483.tif 000012
【図１１】
2012226483.tif 000013
【図１２】
2012226483.tif 000014
【図１３】
2012226483.tif 000015