(57)【要約】  共有デバイス１０５へのアクセスによって発生するアプリのストールを検出する。デバイス監視装置（１０３＿０）は、設定部（２０１＿０）、設定部（２０１＿１）によって、第１ＣＰＵによる共有デバイス（１０５＿１）へのアクセスに基づいて、タイマー（２０７）に対しアクセス時間の計測開始を設定する。タイマー（２０７）による計測開始後、デバイス監視装置（１０３＿０）は、アクセス時間が共有デバイス応答時間ＤＢ（１０８＿０）に格納されている所定時間を超えることを検出する。アクセス時間が所定時間を超えたことを検出後、デバイス監視装置（１０３＿０）は、異常検出部（２０３）によって、検出信号を出力する。
2012066622.tif 000002
【特許請求の範囲】
【請求項１】
第１アプリケーションの実行開始に基づいて第１ＣＰＵに対応するドライバを活性化し、
周辺デバイスへのアクセスに基づいてアクセス時間の計測を開始し、
前記アクセス時間が所定時間を超える場合には前記ドライバをリセットするための検出信号を出力するとともに、前記第１ＣＰＵから前記周辺デバイスに書き込まれるデータを保持するレジスタへの書き込みを禁止すること
を特徴とするアクセス方法。
【請求項２】
前記所定時間は、前記周辺デバイスの応答時間を格納するメモリから参照されること
を特徴とする請求項１に記載のアクセス方法。
【請求項３】
前記周辺デバイスから前記アクセスに対する応答信号が出力される場合には、前記所定時間と前記アクセス時間との比較を停止すること
を特徴とする請求項１または請求項２に記載のアクセス方法。
【請求項４】
前記レジスタは書き込みが禁止される前に書き込まれたデータを保持すること
を特徴とする請求項１乃至請求項３の何れか一の請求項に記載のアクセス方法。
【請求項５】
前記検出信号に基づいて前記ドライバがリセットされた後に前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
を特徴とする請求項１乃至請求項４の何れか一の請求項に記載のアクセス方法。
【請求項６】
前記レジスタのデータが前記周辺デバイスに書き込まれた後に、第２ＣＰＵによって実行される第２アプリケーションが前記周辺デバイスへアクセスすること
を特徴とする請求項５に記載のアクセス方法。
【請求項７】
第１アプリケーションを実行する第１ＣＰＵと、
前記第１アプリケーションによってアクセスされる周辺デバイスと、
を含み、
前記周辺デバイスに、タイマーと第１検出回路と第２検出回路とレジスタとを含む仮想レジスタを設定し、
前記タイマーは前記アクセスに応答してアクセス時間を計測し、
前記第１検出回路は前記アクセス時間と所定時間とを比較し、
前記第２検出回路は前記アクセス時間が前記所定時間を超えているときに検出信号を出力し、前記第１ＣＰＵから前記周辺デバイスに書き込まれるデータの前記レジスタへの書き込みを停止すること
を特徴とするマルチコアプロセッサシステム。
【請求項８】
前記検出信号に基づいて、前記第１ＣＰＵに対応するドライバがリセットされること
を特徴とする請求項７に記載のマルチコアプロセッサシステム。
【請求項９】
前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
を特徴とする請求項８に記載のマルチコアプロセッサシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象となるデバイスにアクセスするアクセス方法、およびマルチコアプロセッサシステムに関する。
【背景技術】
【０００２】
従来から、情報処理装置内外に接続されたデバイスを監視する装置として、ウォッチドッグタイマーや、ダイアグノーシス装置といった装置が存在する。これらの装置を利用し、周期的に各デバイスを点検し、デバイスの異常を検出する技術も存在する。また、バックアップシステムをメインシステムとは別に管理しておき、メインシステム内のデバイスの異常を検出した場合に、メインシステムとバックアップシステムを切り替える技術が存在する。【０００３】
また、異常が発生した際の技術として、複数のコアを含むマルチコアプロセッサシステムの入出力装置の付加装置を設け、起動ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）番号を記録するという技術が開示されている（たとえば、下記特許文献１を参照。）。また、異常発生後の復元の技術として、ＣＰＵの補助を行うコプロセッサ制御において、ハングアップを検出し、ハングアップしたコプロセッサをリセットするという技術が開示されている（たとえば、下記特許文献２を参照。）。【０００４】
また、デバイス間の応答時間を短縮させる技術として、複数ＣＰＵと、複数Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）共有システムにおいて制御装置を設け、起動Ｉ／Ｏが動作中であれば制御信号を記憶し、動作完了後、ダミーＩ／Ｏを送信するという技術が開示されている（たとえば、下記特許文献３を参照。）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開昭５５−１０８０２６号公報
【特許文献２】特表２００７−５０７０３４号公報
【特許文献３】特開平６−２０８５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述した従来技術において、特許文献１、特許文献２にかかる技術では、ハードウェアの障害による異常を対象としていた。しかしながら、ソフトウェアによるデバイスへのアクセスにより発生する障害については、特許文献１、特許文献２にかかる技術では正常と判断されてしまい、異常状態を見落としてしまうという問題があった。【０００７】
また、異常状態を見落としてしまうと、マルチコアプロセッサシステムの場合、問題のあるアプリケーションソフトウェア（以下、アプリ）が共有デバイスへのアクセス権を取得したままストールし、他のアプリが共有デバイスへのアクセス権を取得できない状態が発生する。結果、アクセス権を取得できなかった他のアプリもストールするという、ストールが連鎖的に発生するという問題があった。また、ストールが連鎖的に発生した場合、ストールしたアプリのうち、何れのアプリが問題のあるソフトウェアであるのかを切り分けなければならないという問題があった。【０００８】
本発明は、上述した従来技術による問題点を解消するため、共有デバイスへのアクセスによって発生するアプリのストールを検出できるアクセス方法、およびマルチコアプロセッサシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するため、開示のアクセス方法は、第１アプリケーションの実行開始に基づいて第１ＣＰＵに対応するドライバを活性化し、周辺デバイスへのアクセスに基づいてアクセス時間の計測を開始し、アクセス時間が所定時間を超える場合にはドライバをリセットするための検出信号を出力するとともに、第１ＣＰＵから周辺デバイスに書き込まれるデータを保持するレジスタへの書き込みを禁止する。
【発明の効果】
【００１０】
本アクセス方法、およびマルチコアプロセッサシステムによれば、共有デバイスへのアクセスによって発生するアプリのストールを検出できるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。
【図２】デバイス監視装置１０３の機能を示すブロック図である。
【図３】マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。
【図４】マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。
【図５】マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。
【図６】マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。
【図７】デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。
【図８】マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。
【図９】マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、開示のアクセス方法、およびマルチコアプロセッサシステムの好適な実施の形態を詳細に説明する。
【００１３】
（マルチコアプロセッサシステム１００のハードウェアおよびソフトウェア）
図１は、実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。図１において、マルチコアプロセッサシステム１００は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎと、ウォッチドッグタイマー１０２と、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１と、を含む。各部は、バス１０４によってそれぞれ接続されている。本実施の形態にかかるマルチコアプロセッサシステム１００は、携帯電話等といった、小型の端末装置を想定している。また、図１に図示していないが、バス１０４には、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、フラッシュＲＯＭといった、記憶装置が接続されている。
【００１４】
また、マルチコアプロセッサシステム１００は、共有デバイス１０５＿０〜共有デバイス１０５＿３を含む。共有デバイス１０５＿０、共有デバイス１０５＿１は、デバイス監視装置１０３＿０を経由してバス１０４と接続しており、共有デバイス１０５＿２は、デバイス監視装置１０３＿１を経由してバス１０４と接続している。共有デバイス１０５＿３は、直接バス１０４と接続している。
【００１５】
また、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、それぞれ、割込入力端子であるＩＮＴ（ＩＮＴｅｒｒｕｐｔ）端子１０６＃０〜ＩＮＴ端子１０６＃ｎを含む。ここで、ｎは０以上の整数である。なお、接尾記号“＃ｎ”は、ｎ番目のＣＰＵに対する記号であることを示している。たとえば、ＩＮＴ端子１０６＃ｎは、ＣＰＵ＃ｎに含まれる割込入力端子であることを示している。
【００１６】
続けて、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、ダミーレジスタ１０７＿０、ダミーレジスタ１０７＿１を含み、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１にアクセス可能である。また、共有デバイス１０５＿０〜共有デバイス１０５＿３は、共有デバイス１０５の動作を制御する制御レジスタ１０９＿０〜制御レジスタ１０９＿３を含む。
【００１７】
ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、マルチコアプロセッサシステム１００の全体の制御を司る。ここで、マルチコアプロセッサシステム１００は、複数のコアを含むマルチコアプロセッサシステムとなる。また、マルチコアプロセッサシステム１００は、コアが１つであるシングルコアプロセッサシステムであってもよい。また、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、キャッシュメモリやレジスタを含む。
【００１８】
ウォッチドッグタイマー１０２は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎ、共有デバイス１０５＿０〜共有デバイス１０５＿３などが停止していないかを監視する診断回路である。たとえば、ウォッチドッグタイマー１０２は、ＣＰＵ１０１、共有デバイス１０５等が、過電圧を受けて停止した際に、ＣＰＵ１０１、共有デバイス１０５等の異常を検出する。また、ウォッチドッグタイマー１０２は、デバイス監視装置１０３から、共有デバイス１０５の異常状態の通知を受ける。
【００１９】
デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、共有デバイス１０５＿０〜共有デバイス１０５＿３を監視する装置である。また、デバイス監視装置１０３は、監視対象となる共有デバイス１０５の優先度を設定し、優先度が高い共有デバイス１０５を１つのデバイス監視装置１０３単独で監視し、他の共有デバイス１０５群を、１つのデバイス監視装置１０３が一括して監視してもよい。
【００２０】
具体的には、共有デバイス１０５＿２は、停止状態が好ましくないため、監視の優先度が高い。したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿２に対してデバイス監視装置１０３＿１単独による監視を行うように設計されている。また、共有デバイス１０５＿３は、停止状態であってもマルチコアプロセッサシステム１００の動作に影響しなく、監視の優先度が低い。
【００２１】
したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿３に対してデバイス監視装置１０３による監視を行わないように設計されている。共有デバイス１０５＿０、共有デバイス１０５＿１は、比較的制御が緩慢な共有デバイス１０５として定義されており、監視の優先度が中間に設定されている。マルチコアプロセッサシステム１００は、共有デバイス１０５＿０、共有デバイス１０５＿１に対してデバイス監視装置１０３＿０が一括して監視を行うように設計されている。
【００２２】
また、デバイス監視装置１０３は、バス１０４、監視対象の共有デバイス１０５と接続されており、監視対象の共有デバイス１０５と等しい数分となる制御線１１０、制御線１１２、データ線１１１、データ線１１３を有する。
【００２３】
たとえば、デバイス監視装置１０３＿０は、１つ目の監視対象である共有デバイス１０５＿０に対応する、バス１０４側の制御線１１０＿０、データ線１１１＿０と、共有デバイス１０５＿０側の制御線１１２＿０、データ線１１３＿０を有する。さらに、デバイス監視装置１０３＿０は、２つ目の監視対象である共有デバイス１０５＿１に対応する、バス１０４側の制御線１１０＿１、データ線１１１＿１と、共有デバイス１０５＿１側の制御線１１２＿１、データ線１１３＿１を有する。なお、デバイス監視装置１０３の機能については、図２にて後述する。
【００２４】
共有デバイス１０５＿０、共有デバイス１０５＿３は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃３から利用される周辺デバイスである。具体的には、通信ユニット、カメラデバイス、オーディオデバイス、ディスプレイ、キーボード等である。また、デバイス監視装置１０３に対する監視の優先度が高く設定されている共有デバイス１０５＿２の具体例としては、通信ユニット等が挙げられる。デバイス監視装置１０３に対する監視の優先度が中間に設定されている共有デバイス１０５＿０、共有デバイス１０５＿１の具体例としては、カメラデバイス、オーディオデバイス等が挙げられる。
【００２５】
ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎは、デバイス監視装置１０３からの割込信号を受信する割込入力端子である。また、図１にて図示していないが、ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎは、共有デバイス１０５等からも割込信号を受信する。
【００２６】
ダミーレジスタ１０７＿０〜ダミーレジスタ１０７＿２は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎによる制御レジスタ１０９＿０〜制御レジスタ１０９＿２に対する書き込み情報を保持する。たとえば、ダミーレジスタ１０７＿０は、制御レジスタ１０９＿０に対する書き込み情報を保持する。なお、ダミーレジスタ１０７は、制御レジスタ１０９の何れのビットに対応する書き込み情報を保持してもよいし、制御レジスタ１０９の一部のビットに対応する書き込み情報を保持してもよい。
【００２７】
なお、共有デバイス１０５には、制御レジスタ１０９以外の他のレジスタが存在し、他のレジスタもダミーレジスタ１０７の保持対象としてもよい。他のレジスタとはたとえば、共有デバイス１０５の動作状況が格納されているステータスレジスタ等である。
【００２８】
デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１は、共有デバイス１０５の制御レジスタ１０９に書き込まれた際の応答時間を記憶する記憶領域である。なお、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１の実体は、前述したバス１０４に接続されたＲＡＭ、ＲＯＭ、フラッシュＲＯＭに存在してもよいし、または、デバイス監視装置１０３内に存在する記憶領域に存在してもよい。
【００２９】
続いて、マルチコアプロセッサシステム１００のソフトウェアとしては、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）１２１＃０〜ＯＳ１２１＃ｎ、ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１、アプリ１２３＿０〜アプリ１２３＿５を含む。
【００３０】
ＯＳ１２１＃０〜ＯＳ１２１＃ｎは、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎを制御するソフトウェアである。たとえば、ＯＳ１２１＃０には、アプリ１２３＿０、アプリ１２３＿１のうち、ＣＰＵ１０１＃０に割り当てるアプリを決定するスケジューラや、決定されたアプリをＣＰＵ１０１＃０に割り当てるディスパッチャ等といったソフトウェアが含まれる。また、ＯＳ１２１＃０〜ＯＳ１２１＃ｎは、共有デバイス１０５に対する排他制御処理を行う。
【００３１】
ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１は、ＯＳ１２１＃０〜ＯＳ１２１＃ｎの提供する機能の一つであり、共有デバイス１０５にアクセスするソフトウェアである。ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１は、アプリ１２３＿０〜アプリ１２３＿５からの呼び出しによって活性化し、対応する共有デバイス１０５にアクセスする。
【００３２】
なお、図１では、ドライバ１２２＃０＿０、ドライバ１２２＃１＿０、…、ドライバ１２２＃ｎ＿０が共有デバイス１０５＿０にアクセスするソフトウェアである。同様に、ドライバ１２２＃０＿１、ドライバ１２２＃１＿１、…、ドライバ１２２＃ｎ＿１が共有デバイス１０５＿１にアクセスするソフトウェアである。また図１に図示していないが、共有デバイス１０５＿２、共有デバイス１０５＿３に対するドライバ１２２も、ＯＳ１２１＃０〜ＯＳ１２１＃ｎ内に存在する。
【００３３】
このように、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎがそれぞれのドライバ１２２を呼び出すことで、１つの共有デバイス１０５に対してアクセスできる。同時のアクセスによる不具合を発生させないため、マルチコアプロセッサシステム１００は、排他制御処理によって、１つの共有デバイス１０５に対してアクセスが競合しないように設計されている。
【００３４】
アプリ１２３＿０〜アプリ１２３＿５は、マルチコアプロセッサシステム１００のユーザにサービスを提供するソフトウェア群である。具体的に、アプリ１２３＿０〜アプリ１２３＿５は、音楽再生アプリ、ゲームアプリ、カメラアプリ等である。アプリ１２３＿０〜アプリ１２３＿５は、ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１を呼び出すことにより、共有デバイス１０５＿０〜共有デバイス１０５＿３を操作する。たとえば、アプリ１２３＿３が音楽再生アプリ、共有デバイス１０５＿１がオーディオデバイスであると想定する。このとき、アプリ１２３＿０は、ドライバ１２２＃１＿１を呼び出して、オーディオデバイスを操作し、音楽再生を実現する。
【００３５】
図２は、デバイス監視装置１０３の機能を示すブロック図である。デバイス監視装置１０３は、設定部２０１＿０、設定部２０１＿１、時差検出部２０２、異常検出部２０３、ＡＣＫ出力部２０４、デバイス制御部２０５、書込部２０６、タイマー２０７を含む。また、デバイス監視装置１０３、共有デバイス１０５は、外部からクロック入力を受けている。
【００３６】
設定部２０１＿０、設定部２０１＿１は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎのうち、第１ＣＰＵによる共有デバイス１０５へのアクセスに基づいて、タイマー２０７に対しアクセス時間の計測開始を設定する機能を有する。アクセス時間とは、共有デバイス１０５へのアクセス時刻を開始時刻とし、共有デバイス１０５からのアクセスに対する応答信号が発生した時刻を終了時刻とした時間である。
【００３７】
たとえば、設定部２０１＿１は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１に対する書き込み要求を検出し、タイマー２０７に対しアクセス時間の計測開始を設定する。また、設定部２０１＿０、設定部２０１＿１は、共有デバイス１０５から、アクセスに対する応答信号が出力された場合、アクセス時間の計測を停止してもよい。また、応答信号とは、ＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）信号である。なお、設定部２０１＿０は、共有デバイス１０５＿０に対するアクセスを検出し、設定部２０１＿１は、共有デバイス１０５＿１に対するアクセスを検出する。なお、設定された情報は、デバイス監視装置１０３の記憶領域、タイマー２０７の設定レジスタ、などの記憶領域に記憶される。
【００３８】
時差検出部２０２は、アクセス時間が所定時間を超えることを検出する機能を有する。なお、所定時間とは、共有デバイス１０５の仕様となる応答時間であり、デバイス応答時間ＤＢ１０８に格納されている。たとえば、時差検出部２０２は、共有デバイス１０５＿１に対する書き込み要求の時刻を開始時刻とするアクセス時間が共有デバイス１０５＿１の応答時間５００［マイクロ秒］を超えたことを検出する。なお、検出結果は、デバイス監視装置１０３の記憶領域に記憶される。
【００３９】
異常検出部２０３は、時差検出部２０２によってアクセス時間が所定時間を超えたことが検出された場合、検出信号を出力する機能を有する。検出信号としては、ウォッチドッグタイマー１０２に対して異常状態を示す検出信号と、ＩＮＴ端子１０６に対して異常状態を示す検出信号とがある。たとえば、異常検出部２０３は、共有デバイス１０５＿１の仕様となる応答時間５００［マイクロ秒］を超えた場合に、ウォッチドッグタイマー１０２とＩＮＴ端子１０６に対して検出信号を出力する。
【００４０】
ＡＣＫ出力部２０４は、第１のＣＰＵが共有デバイス１０５にアクセス中に、共有デバイス１０５にアクセスしてきた第２のＣＰＵに対し、ダミーＡＣＫ信号を出力する機能を有する。ダミーＡＣＫ信号は、ＡＣＫ信号と同内容の信号である。たとえば、ＡＣＫ出力部２０４は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１にアクセス中に、共有デバイス１０５＿１にアクセスしてきたＣＰＵ１０１＃１に対し、ダミーＡＣＫ信号を出力する。なお、ダミーＡＣＫ信号を出力したという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
【００４１】
デバイス制御部２０５は、第１のＣＰＵに対するアクセスの応答信号がない共有デバイス１０５に対し、リセットの指示を行う機能を有する。たとえば、デバイス制御部２０５は、ＣＰＵ１０１＃ｎに対するアクセスの応答信号がない共有デバイス１０５＿１に対し、リセットの指示を行う。なお、リセットの指示が行われたという情報は、デバイス監視装置１０３の記憶領域に記憶される。
【００４２】
書込部２０６は、デバイス制御部２０５によって共有デバイス１０５がリセット完了した後、ダミーレジスタ１０７の内容を制御レジスタ１０９に書き込む機能を有する。たとえば、書込部２０６は、共有デバイス１０５＿１がリセット完了した後に、ダミーレジスタ１０７＿１の内容を制御レジスタ１０９＿１に書き込む。なお、書き込んだという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
【００４３】
タイマー２０７は、アクセス時間を計測する機能を有する。たとえば、タイマー２０７は、アクセス開始時刻から、外部から入力されたクロックを計数することで、アクセス時間を計測する。また、タイマー２０７は、設定部２０１＿０、設定部２０１＿１によって計測開始、計測停止する。
【００４４】
以下、デバイス監視装置１０３の機能を用いて、図３〜図６にて、マルチコアプロセッサシステム１００が通常運用状態から、異常状態となり、さらに異常状態からの復元動作までの一連の動作について説明を行う。また、図３〜図６では、アプリ１２３＿３を音楽再生アプリと想定し、アプリ１２３＿５を音声が発生するゲームアプリと想定し、共有デバイス１０５＿１をオーディオデバイスと想定する。
【００４５】
図３は、マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。通常運用時におけるマルチコアプロセッサシステム１００は、ＯＳ１２１＃０〜ＯＳ１２１＃ｎがドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１を調停、切り替えながら動作している。
【００４６】
具体的には、アプリ１２３＿３は、音楽データのデコードおよびＤＡ変換を行い、変換結果をドライバ１２２＃１＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音楽を再生させている。また、アプリ１２３＿５は、音声データをドライバ１２２＃ｎ＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音声を再生させている。ユーザには、アプリ１２３＿５から発せられる音声データと、アプリ１２３＿３から発せられる音楽データとが合わさった音が聞こえている状態である。
【００４７】
通常運用時におけるデバイス監視装置１０３は、たとえば、ドライバ１２２＃１＿１からの書き込み要求を受けると、制御レジスタ１０９＿１に、書き込み対象のデータを書き込むとともに、対応するダミーレジスタ１０７＿１にも書き込み対象のデータを書き込む。書き込み要求を受けると、設定部２０１＿１は、タイマー２０７による書き込み要求に対応する応答信号が発生するまでのアクセス時間の計測開始を設定する。
【００４８】
図３で示すマルチコアプロセッサシステム１００は通常運用時であるため、共有デバイス１０５＿１は、仕様である応答時間＝５００［マイクロ秒］以内に書き込み要求に対応する応答信号をＣＰＵ１０１＃１に送信する。応答信号となるＡＣＫ信号が共有デバイス１０５＿１から発生すると、設定部２０１＿１は、タイマー２０７によるアクセス時間の計測停止を設定する。
【００４９】
図４は、マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。図４で示すマルチコアプロセッサシステム１００では、アプリ１２３＿５が障害によりストールした状態を示している。障害の内容として、たとえば、アプリ１２３＿５が不正な値をドライバ１２２＃ｎ＿１を経由して共有デバイス１０５＿１に書き込んだ場合である。
【００５０】
このとき、アプリ１２３＿５が、マルチコアプロセッサシステム１００の共有資源である、共有デバイス１０５＿１へのアクセス権を取得したままストールしてしまうことがある。なお、図４の状態では、共有デバイス１０５＿１が故障しているわけではないため、ウォッチドッグタイマー１０２では、異常状態を検出することができない。また、ドライバ１２２＃ｎ＿１は、アプリ１２３＿５によってロックされた状態である。
【００５１】
もし、マルチコアプロセッサシステム１００がシングルコアプロセッサシステムであれば、アプリ１２３＿５のストールとともに、ＯＳ１２１がストールすることになる。コアが複数存在するマルチコアプロセッサシステム１００は、ＣＰＵ１０１ごとに独立したＯＳを動作させることにより、ストールの影響を最小限に食い止めることが可能である。しかし、ＣＰＵ１０１＃１上のアプリ１２３＿３が共有デバイス１０５＿１にアクセスを行おうとした場合、応答信号が返らない状態、または、アクセスが行えない状態となる。
【００５２】
本実施の形態にかかるマルチコアプロセッサシステム１００は、このような、応答信号が返らない状態、または、アクセスが行えない状態を防ぐ。初めに、設定部２０１＿１は、アプリ１２３＿５による書き込み時に、タイマー２０７の計測開始を設定する。
【００５３】
図５は、マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。図５で示すマルチコアプロセッサシステム１００は、図４にて計測開始したタイマー２０７の経過時間が、デバイス応答時間ＤＢ１０８で設定されている応答時間＝５００［マイクロ秒］を超えた場合を示している。具体的には、マルチコアプロセッサシステム１００が図４で示す状態にて、アプリ１２３＿５が、音声データＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ、Ｆｉｒｓｔ  Ｏｕｔ）に音声データを書き込み、制御レジスタ１０９＿１にデータセット完了を意味するフラグを設定した場合である。このとき、共有デバイス１０５＿１の仕様として、共有デバイス１０５＿１は、フラグ設定から５００［マイクロ秒］にて受信完了を示すＡＣＫ信号を発行すると定められている場合を想定している。
【００５４】
書き込み要求からの経過時間が５００［マイクロ秒］を超えたことが時差検出部２０２によって検出された場合、異常検出部２０３は、ウォッチドッグタイマー１０２に対して異常状態を示す検出信号を出力する。また、異常検出部２０３は、ＩＮＴ端子１０６に対しても、共有デバイス１０５＿１の異常状態を示す検出信号を通知する。なお、ＩＮＴ端子１０６から検出信号を受信したＣＰＵ１０１は、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行する。なお、ソフトウェアの検出要求は、ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎにブロードキャスト送信してもよいし、アクセスを行ったＣＰＵ１０１＃１に対するＩＮＴ端子１０６＃１のみに送信してもよい。
【００５５】
また、ＣＰＵ１０１＃１に応答信号が返らない状態である場合、ＡＣＫ出力部２０４が、ダミーＡＣＫ信号をＣＰＵ１０１＃１に送信し、アプリ１２３＿３の停止を防ぐ。従来例にかかるマルチコアプロセッサシステム１００では、ＡＣＫ信号が返らずにＯＳ１２１がタイムアウトを検出し、アプリ１２３＿３を異常終了するという対応が取られていた。しかし、ＯＳ１２１によるタイムアウトが数秒かかる場合や、または、ＯＳ１２１がタイムアウトせずに、ストールする場合も存在していた。本実施の形態にかかるマルチコアプロセッサシステム１００では、ダミーＡＣＫ信号を送信することで、アプリ１２３＿３の異常終了を避けることができる。
【００５６】
図６は、マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。図６で示すマルチコアプロセッサシステム１００は、図５にて異常検出部２０３、ＡＣＫ出力部２０４が動作した後である。図５にて異常状態の通知を受けたウォッチドッグタイマー１０２が、ＣＰＵ１０１＃ｎのウォームスタート要求を通知する。ウォームスタート要求を受信したＣＰＵ１０１＃ｎはソフトリセットが行われる。また、ドライバ１２２＃ｎ＿１は、ロックが解除され、共有デバイス１０５＿１へのアクセス権を解放する。
【００５７】
また、ＩＮＴ端子１０６＃ｎから検出信号を受信したＣＰＵ１０１＃ｎは、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行し、アプリ１２３＿５を検出する。検出後、ＣＰＵ１０１＃ｎは、検出されたアプリ１２３＿５を強制終了させる。
【００５８】
また、デバイス制御部２０５が共有デバイス１０５＿１に対して、リセットを行った後に、書込部２０６がダミーレジスタ１０７＿１に書き込まれていたデータを制御レジスタ１０９＿１に書き込む。以上の動作により、マルチコアプロセッサシステム１００は、異常状態から復旧することになる。問題のあったアプリ１２３＿５が強制終了し、アプリ１２３＿３については正常に処理を続行することができる。
【００５９】
図７は、デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。デバイス応答時間ＤＢ１０８は、デバイス名、応答時間という２つのフィールドを含む。デバイス名フィールドには、共有デバイス１０５の名称が格納される。また、共有デバイス１０５が一意に特定できるＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）であってもよい。応答時間フィールドには、共有デバイス１０５の応答時間が格納される。
【００６０】
たとえば、監視の優先度が中間の共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿０には、共有デバイス１０５＿０、共有デバイス１０５＿１の応答時間が、それぞれ、４００［マイクロ秒］、５００［マイクロ秒］、と格納されている。また、監視の優先度が高い共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿１には、共有デバイス１０５＿２の応答時間が、１０［ミリ秒］と格納されている。また、応答時間フィールドに関しては、ユーザによって自由に変更されてもよい。
【００６１】
図２で示したデバイス監視装置１０３の機能、および図７で示したデバイス応答時間ＤＢ１０８の記憶内容に基づいて、デバイス監視装置１０３は、異常状態からの復元処理を行う。図８、図９にて、デバイス監視装置１０３は、異常状態を検出し、続けて復元処理のフローチャートを示す。
【００６２】
また、図８、図９で示すフローチャートでは、アプリ１２３＿５の共有デバイス１０５＿１に対する書き込み要求によって、アプリ１２３＿５がストールし、その後、アプリ１２３＿３が共有デバイス１０５＿１に対して書き込み要求を行うことを想定する。また、アプリ１２３＿５、ドライバ１２２＃ｎ＿１は、ＣＰＵ１０１＃ｎによって実行され、アプリ１２３＿３は、ＣＰＵ１０１＃１によって実行される。なお、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出すが、図８、図９では、ドライバ１２２＃１＿１の処理については、ドライバ１２２＃ｎ＿１と等しいため、図示せず、ドライバ１２２＃ｎ＿１の処理番号を引用して説明する。
【００６３】
図８は、マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。アプリ１２３＿５は、ドライバ１２２＃ｎ＿１をオープンする（ステップＳ８０１）。オープンされたドライバ１２２＃ｎ＿１は、共有デバイス１０５＿１に対するアクセス権を取得する（ステップＳ８０２）。続けて、ドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１の退避・復元を行う（ステップＳ８０３）。
【００６４】
制御レジスタ１０９＿１の退避・復元が行われた後、アプリ１２３＿５は、ドライバ１２２＃ｎ＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８０４）。呼び出されたドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１に書き込み要求を行う（ステップＳ８０５）。
【００６５】
書き込み要求を受信したデバイス監視装置１０３＿０は、設定部２０１＿１によって、タイマー２０７の計測開始を設定する（ステップＳ８０６）。続けて、デバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１と制御レジスタ１０９＿１に書き込み要求となるデータを書き込む（ステップＳ８０７）。
【００６６】
書き込み要求後、アプリ１２３＿５は、異常発生を検出したかを判断する（ステップＳ８０８）。異常が発生した場合（ステップＳ８０８：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリ可能か否かを判断する（ステップＳ８０９）。ソフトウェアリカバリ可能である場合（ステップＳ８０９：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリを実行する（ステップＳ８１０）。ソフトウェアリカバリ不可能である場合（ステップＳ８０９：Ｎｏ）、アプリ１２３＿５は、異常状態となり（ステップＳ８１１）、以後、アプリ１２３＿５はストールした状態となる。
【００６７】
異常発生を検出していない場合（ステップＳ８０８：Ｎｏ）、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。なお、ステップＳ８０８：Ｎｏとなった場合、共有デバイス１０５＿１よりＡＣＫ信号が送られるため、ステップＳ８０６で設定されたタイマー２０７の計測が停止する。ステップＳ８１０実行後も、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。
【００６８】
続けて、アプリ１２３＿５がストール中にアプリ１２３＿３による共有デバイス１０５＿１へのアクセスが行われる場合を想定する。アプリ１２３＿３は、ドライバ１２２＃１＿１をオープンする（ステップＳ８１２）。ステップＳ８１２の処理後、ドライバ１２２＃１＿１が実行されるが、ステップＳ８１２の処理後のドライバ１２２＃１＿１の処理は、ステップＳ８０２、ステップＳ８０３の処理と等しい。しかしながら、アプリ１２３＿５が共有デバイス１０５＿１に対するアクセス権を有したままストールしたために、アプリ１２３＿３は、共有デバイス１０５＿１に対するアクセス権を取得できない。したがって、ドライバ１２２＃１＿１は、ステップＳ８０３の処理である、制御レジスタ１０９＿１の退避・復元を完了できず、失敗することになる。
【００６９】
続けて、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８１３）。ステップＳ８１３の処理後、ドライバ１２２＃１＿１が実行され、処理としては、ステップＳ８０５の処理と同内容の処理が実行される。
【００７０】
ドライバ１２２＃１＿１より制御レジスタ１０９＿１への書き込み要求を受けたデバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１に書き込む（ステップＳ８１４）。なお、ステップＳ８１４の処理にて、アプリ１２３＿３は共有デバイス１０５＿１に対するアクセス権を有していないため、制御レジスタ１０９＿１に書き込み要求が反映されない。
【００７１】
図９は、マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。デバイス監視装置１０３＿０は、時差検出部２０２によって、タイマー２０７の計測によるアクセス時間が応答時間を超えたことを検出し、異常状態として検出する（ステップＳ９０１）。異常状態を検出後、デバイス監視装置１０３＿０は、ＡＣＫ出力部２０４によって、ダミーＡＣＫ信号をＣＰＵ１０１＃１に出力する（ステップＳ９０２）。ダミーＡＣＫ信号を受けたＣＰＵ１０１＃１は、アプリ１２３＿３を正常実行する（ステップＳ９０３）。
【００７２】
また、異常状態を検出後、デバイス監視装置１０３＿０は、異常検出部２０３によって、検出信号をウォッチドッグタイマー１０２とＩＮＴ端子１０６に出力する（ステップＳ９０４）。
【００７３】
ＩＮＴ端子１０６＃ｎより、検出信号を受信したＣＰＵ１０１＃ｎが、アプリ１２３＿５を強制終了する（ステップＳ９０５）。また、ドライバ１２２＃ｎ＿１は、ウォッチドッグタイマー１０２によって検出信号を受信したＯＳ１２１＃ｎのウォームスタートにより、共有デバイス１０５＿１に対するアクセス権を解放する（ステップＳ９０６）。
【００７４】
続けて、デバイス監視装置１０３＿０は、異常検出部２０３によって、ダミーレジスタ１０７＿１に対する書き込みを禁止する（ステップＳ９０７）。書き込み禁止後、デバイス監視装置１０３は、デバイス制御部２０５によって、共有デバイス１０５＿１に対してリセットの指示を行う（ステップＳ９０８）。共有デバイス１０５＿１のリセット完了後、デバイス監視装置１０３＿０は、書込部２０６によって、ダミーレジスタ１０７＿１の内容を、制御レジスタ１０９＿１に書き込む（ステップＳ９０９）。書き込み後、デバイス監視装置１０３＿０は、ダミーレジスタ１０７に対する書き込み禁止を解除する（ステップＳ９１０）。
【００７５】
なお、図８、図９に示したフローチャートでは、問題のあるアプリ１２３＿５がストールした後、問題のないアプリ１２３＿３が共有デバイス１０５＿１にアクセスしている。もし、問題のあるアプリ１２３＿５がストールした後に、何れのアプリも共有デバイス１０５＿１にアクセスしない場合でも、マルチコアプロセッサシステム１００は、異常状態を復元することができる。何れのアプリも共有デバイス１０５＿１にアクセスしない場合、デバイス監視装置１０３＿０は、ステップＳ８１４、ステップＳ９０２、ステップＳ９０９の処理を行わない。
【００７６】
以上説明したように、アクセス方法、およびマルチコアプロセッサシステムによれば、ＣＰＵからドライバによるアクセス開始時刻以後、応答信号が返らずに所定時間が経過した場合、デバイス監視装置が共有デバイスの異常状態として検出信号を出力する。これにより、マルチコアプロセッサシステムは、ドライバが共有デバイスへのアクセスによって発生するストールを検出できる。
【００７７】
また、デバイス監視装置は、所定時間について、共有デバイスの仕様となる応答時間を格納するメモリから参照してもよい。これにより、マルチコアプロセッサシステムは、応答時間の異なる共有デバイスの動作に合わせて、異常状態を検出できる。また、マルチコアプロセッサシステムは、ユーザの指示等により、所定時間を変更してもよい。
【００７８】
また、デバイス監視装置は、共有デバイスからアクセスに対する応答信号が出力される場合には、所定時間とアクセス開始時刻からのアクセス時間との比較を停止する。これにより、マルチコアプロセッサシステムは、共有デバイスが正常に動作している場合に異常状態として検出してしまうことがないようにできる。
【００７９】
また、デバイス監視装置は、ＣＰＵから共有デバイスに対して書き込まれるデータを保持する記憶領域を有し、異常状態を検出した場合に、記憶領域に対する保持を禁止してもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスに書き込まれなかったデータを、他のＣＰＵ等からによる上書きから保護することができる。
【００８０】
また、デバイス監視装置は、異常状態を検出する前に記憶領域に書き込まれたデータを、異常検出後も保持していてもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスの制御レジスタに書き込まれなかったデータを保持することができる。
【００８１】
また、デバイス監視装置は、検出信号に基づいてドライバがリセットされた後、記憶領域に保持していたデータを、共有デバイスの制御レジスタに書き込んでもよい。これにより、マルチコアプロセッサシステムは、異常状態から復元でき、異常状態を発生させたアプリとは異なる、問題のないアプリによって発生したデータを、共有デバイスに書き込ませることができる。
【００８２】
また、デバイス監視装置は、記憶領域に保持していたデータを共有デバイスに書き込んだ後、異常状態を発生させたアプリを実行していたＣＰＵとは異なる他のＣＰＵによって実行される別のアプリからの共有デバイスへのアクセスを受け付けてもよい。これにより、マルチコアプロセッサシステムは、別のアプリがストールすることがなく、ストールが連鎖的に発生することを避けることができる。
【００８３】
また、従来例にかかるマルチコアプロセッサシステムでは、ＯＳがアプリからの応答がないことを異常状態として検出していた。この場合、異常状態として検出できるまでに数秒かかってしまうため、ストールの連鎖が発生してしまい、また、ユーザの利便性が下がるといった問題があった。本実施の形態にかかるマルチコアプロセッサシステムでは、共有デバイスの応答時間という、短い時間で異常状態を検出できるため、ストールの連鎖が発生する前に異常状態を検出できるうえ、ユーザにも異常状態が発生したことを気づかれにくいという効果がある。
【００８４】
また、従来例にかかるマルチコアプロセッサシステムでは、ストールが連鎖的に発生した場合に、ユーザが装置の故障と錯覚する可能性がある。錯覚した結果、設計者等が故障に対する対応が発生するという問題があった。装置の故障となった場合、故障の点検のために装置を回収することになり、対応にかかるコストが大きくなるという問題もあった。また、ソフトウェアによる異常発生は、様々な条件が重なったときに発生することもあり、異常状態の再現が困難であるという問題もあった。
【００８５】
しかし、本実施の形態にかかるマルチコアプロセッサシステムでは、問題のあるアプリが強制終了し、他のアプリは正常実行するために、ユーザは装置の故障と錯覚せずにアプリに問題があるということを容易に判断できる。これにより、障害のレポートがあった場合、装置の回収をしなくてもよく、開発者は問題のあるアプリの再配布を行うことで対応できるため、マルチコアプロセッサシステは、対応にかかるコストを小さくすることができる。
【００８６】
また、本実施の形態で説明したデバイス監視装置１０３は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したデバイス監視装置１０３の機能（設定部２０１〜タイマー２０７）をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、デバイス監視装置１０３を製造することができる。
【符号の説明】
【００８７】
１０２  ウォッチドッグタイマー
１０３  デバイス監視装置
１０５  共有デバイス
１０７  ダミーレジスタ
１０８  デバイス応答時間ＤＢ
１０９  制御レジスタ
１１０、１１２  制御線
１１１、１１３  データ線
２０１  設定部
２０２  時差検出部
２０３  異常検出部
２０４  ＡＣＫ出力部
２０５  デバイス制御部
２０６  書込部
２０７  タイマー
【図１】
2012066622.tif 000003
【図２】
2012066622.tif 000004
【図３】
2012066622.tif 000005
【図４】
2012066622.tif 000006
【図５】
2012066622.tif 000007
【図６】
2012066622.tif 000008
【図７】
2012066622.tif 000009
【図８】
2012066622.tif 000010
【図９】
2012066622.tif 000011
【手続補正書】
【提出日】平成25年11月25日(2013.11.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１アプリケーションの実行開始に基づいて複数のＣＰＵのうちの周辺デバイスに対するアクセス権を取得した第１ＣＰＵに対応するドライバを活性化し、
前記第１ＣＰＵが前記周辺デバイスへアクセスを行ってから前記アクセスに対する応答信号が発生するまでの時間を示すアクセス時間の計測を開始し、
前記複数のＣＰＵのうちの前記第１ＣＰＵ以外の他のＣＰＵが前記周辺デバイスに対するアクセス権を取得できない場合、前記周辺デバイスにアクセスせずに前記周辺デバイスに書き込まれるデータを保持するレジスタにアクセスし、
前記アクセス時間が所定時間を超える場合には前記ドライバをリセットするための検出信号を出力するとともに、前記他のＣＰＵから前記レジスタへの書き込みを禁止し、
前記検出信号に基づいて前記ドライバがリセットされた後に前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
を特徴とするアクセス方法。
【請求項２】
前記所定時間は、前記周辺デバイスの応答時間を格納するメモリから参照されること
を特徴とする請求項１に記載のアクセス方法。
【請求項３】
前記周辺デバイスから前記アクセスに対する応答信号が出力される場合には、前記所定時間と前記アクセス時間との比較を停止すること
を特徴とする請求項１または請求項２に記載のアクセス方法。
【請求項４】
前記レジスタは書き込みが禁止される前に書き込まれたデータを保持すること
を特徴とする請求項１乃至請求項３の何れか一の請求項に記載のアクセス方法。
【請求項５】
前記レジスタのデータが前記周辺デバイスに書き込まれた後に、第２ＣＰＵによって実行される第２アプリケーションが前記周辺デバイスへアクセスすること
を特徴とする請求項１乃至請求項４の何れか一の請求項に記載のアクセス方法。
【請求項６】
前記検出信号に基づいて、ソフトウェアによる前記周辺デバイスへのアクセスにより発生する障害によりストールした前記第１アプリケーションを検出し、前記第１アプリケーションを強制終了すること
を特徴とする請求項１乃至請求項５の何れか一の請求項に記載のアクセス方法。
【請求項７】
複数のＣＰＵと、
前記複数のＣＰＵによってアクセスされる周辺デバイスと、
を含み、
前記周辺デバイスに、タイマーと第１検出回路と第２検出回路と前記周辺デバイスに書き込まれるデータを保持するレジスタとを含むデバイス監視装置を接続し、
前記タイマーは、前記周辺デバイスに対するアクセス権を取得した第１ＣＰＵが前記周辺デバイスへ前記アクセスを行ってから前記アクセスに対する応答信号が発生するまでの時間を示すアクセス時間を計測し、
前記複数のＣＰＵのうちの前記第１ＣＰＵ以外の他のＣＰＵは、前記他のＣＰＵが前記周辺デバイスに対するアクセス権を取得できない場合、前記周辺デバイスにアクセスせずに前記レジスタにアクセスし、
前記第１検出回路は前記アクセス時間と所定時間とを比較し、
前記第２検出回路は前記アクセス時間が前記所定時間を超えているときに検出信号を出力し、前記他のＣＰＵから前記周辺デバイスに書き込まれるデータの前記レジスタへの書き込みを停止し、
前記検出信号に基づいて前記第１ＣＰＵに対応するドライバがリセットされた後に前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
を特徴とするマルチコアプロセッサシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象となるデバイスにアクセスするアクセス方法、およびマルチコアプロセッサシステムに関する。
【背景技術】
【０００２】
従来から、情報処理装置内外に接続されたデバイスを監視する装置として、ウォッチドッグタイマーや、ダイアグノーシス装置といった装置が存在する。これらの装置を利用し、周期的に各デバイスを点検し、デバイスの異常を検出する技術も存在する。また、バックアップシステムをメインシステムとは別に管理しておき、メインシステム内のデバイスの異常を検出した場合に、メインシステムとバックアップシステムを切り替える技術が存在する。
【０００３】
また、異常が発生した際の技術として、複数のコアを含むマルチコアプロセッサシステムの入出力装置の付加装置を設け、起動ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）番号を記録するという技術が開示されている（たとえば、下記特許文献１を参照。）。また、異常発生後の復元の技術として、ＣＰＵの補助を行うコプロセッサ制御において、ハングアップを検出し、ハングアップしたコプロセッサをリセットするという技術が開示されている（たとえば、下記特許文献２を参照。）。
【０００４】
また、デバイス間の応答時間を短縮させる技術として、複数ＣＰＵと、複数Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）共有システムにおいて制御装置を設け、起動Ｉ／Ｏが動作中であれば制御信号を記憶し、動作完了後、ダミーＩ／Ｏを送信するという技術が開示されている（たとえば、下記特許文献３を参照。）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開昭５５−１０８０２６号公報
【特許文献２】特表２００７−５０７０３４号公報
【特許文献３】特開平６−２０８５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述した従来技術において、特許文献１、特許文献２にかかる技術では、ハードウェアの障害による異常を対象としていた。しかしながら、ソフトウェアによるデバイスへのアクセスにより発生する障害については、特許文献１、特許文献２にかかる技術では正常と判断されてしまい、異常状態を見落としてしまうという問題があった。
【０００７】
また、異常状態を見落としてしまうと、マルチコアプロセッサシステムの場合、問題のあるアプリケーションソフトウェア（以下、アプリ）が共有デバイスへのアクセス権を取得したままストールし、他のアプリが共有デバイスへのアクセス権を取得できない状態が発生する。結果、アクセス権を取得できなかった他のアプリもストールするという、ストールが連鎖的に発生するという問題があった。また、ストールが連鎖的に発生した場合、ストールしたアプリのうち、何れのアプリが問題のあるソフトウェアであるのかを切り分けなければならないという問題があった。
【０００８】
本発明は、上述した従来技術による問題点を解消するため、共有デバイスへのアクセスによって発生するアプリのストールを検出できるアクセス方法、およびマルチコアプロセッサシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するため、開示のアクセス方法は、第１アプリケーションの実行開始に基づいて第１ＣＰＵに対応するドライバを活性化し、周辺デバイスへのアクセスに基づいてアクセス時間の計測を開始し、アクセス時間が所定時間を超える場合にはドライバをリセットするための検出信号を出力するとともに、第１ＣＰＵから周辺デバイスに書き込まれるデータを保持するレジスタへの書き込みを禁止する。
【発明の効果】
【００１０】
本アクセス方法、およびマルチコアプロセッサシステムによれば、共有デバイスへのアクセスによって発生するアプリのストールを検出できるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。
【図２】デバイス監視装置１０３の機能を示すブロック図である。
【図３】マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。
【図４】マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。
【図５】マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。
【図６】マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。
【図７】デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。
【図８】マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。
【図９】マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、開示のアクセス方法、およびマルチコアプロセッサシステムの好適な実施の形態を詳細に説明する。
【００１３】
（マルチコアプロセッサシステム１００のハードウェアおよびソフトウェア）
図１は、実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。図１において、マルチコアプロセッサシステム１００は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎと、ウォッチドッグタイマー１０２と、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１と、を含む。各部は、バス１０４によってそれぞれ接続されている。本実施の形態にかかるマルチコアプロセッサシステム１００は、携帯電話等といった、小型の端末装置を想定している。また、図１に図示していないが、バス１０４には、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、フラッシュＲＯＭといった、記憶装置が接続されている。
【００１４】
また、マルチコアプロセッサシステム１００は、共有デバイス１０５＿０〜共有デバイス１０５＿３を含む。共有デバイス１０５＿０、共有デバイス１０５＿１は、デバイス監視装置１０３＿０を経由してバス１０４と接続しており、共有デバイス１０５＿２は、デバイス監視装置１０３＿１を経由してバス１０４と接続している。共有デバイス１０５＿３は、直接バス１０４と接続している。
【００１５】
また、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、それぞれ、割込入力端子であるＩＮＴ（ＩＮＴｅｒｒｕｐｔ）端子１０６＃０〜ＩＮＴ端子１０６＃ｎを含む。ここで、ｎは０以上の整数である。なお、接尾記号“＃ｎ”は、ｎ番目のＣＰＵに対する記号であることを示している。たとえば、ＩＮＴ端子１０６＃ｎは、ＣＰＵ＃ｎに含まれる割込入力端子であることを示している。
【００１６】
続けて、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、ダミーレジスタ１０７＿０、ダミーレジスタ１０７＿１を含み、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１にアクセス可能である。また、共有デバイス１０５＿０〜共有デバイス１０５＿３は、共有デバイス１０５の動作を制御する制御レジスタ１０９＿０〜制御レジスタ１０９＿３を含む。
【００１７】
ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、マルチコアプロセッサシステム１００の全体の制御を司る。ここで、マルチコアプロセッサシステム１００は、複数のコアを含むマルチコアプロセッサシステムとなる。また、マルチコアプロセッサシステム１００は、コアが１つであるシングルコアプロセッサシステムであってもよい。また、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎは、キャッシュメモリやレジスタを含む。
【００１８】
ウォッチドッグタイマー１０２は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎ、共有デバイス１０５＿０〜共有デバイス１０５＿３などがハードウェアの障害により停止していないかを監視する診断回路である。たとえば、ウォッチドッグタイマー１０２は、ＣＰＵ１０１、共有デバイス１０５等が、過電圧を受けて停止した際に、ＣＰＵ１０１、共有デバイス１０５等の異常を検出する。また、ウォッチドッグタイマー１０２は、デバイス監視装置１０３から、共有デバイス１０５においてソフトウェアによる周辺デバイスへのアクセスにより発生する障害による異常状態の通知を受ける。
【００１９】
デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、共有デバイス１０５＿０〜共有デバイス１０５＿３がソフトウェアによる周辺デバイスへのアクセスにより発生する障害による異常状態が発生していないかを監視する装置である。また、デバイス監視装置１０３は、監視対象となる共有デバイス１０５の優先度を設定し、優先度が高い共有デバイス１０５を１つのデバイス監視装置１０３単独で監視し、他の共有デバイス１０５群を、１つのデバイス監視装置１０３が一括して監視してもよい。
【００２０】
具体的には、共有デバイス１０５＿２は、停止状態が好ましくないため、監視の優先度が高い。したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿２に対してデバイス監視装置１０３＿１単独による監視を行うように設計されている。また、共有デバイス１０５＿３は、停止状態であってもマルチコアプロセッサシステム１００の動作に影響しなく、監視の優先度が低い。
【００２１】
したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿３に対してデバイス監視装置１０３による監視を行わないように設計されている。共有デバイス１０５＿０、共有デバイス１０５＿１は、比較的制御が緩慢な共有デバイス１０５として定義されており、監視の優先度が中間に設定されている。マルチコアプロセッサシステム１００は、共有デバイス１０５＿０、共有デバイス１０５＿１に対してデバイス監視装置１０３＿０が一括して監視を行うように設計されている。
【００２２】
また、デバイス監視装置１０３は、バス１０４、監視対象の共有デバイス１０５と接続されており、監視対象の共有デバイス１０５と等しい数分となる制御線１１０、制御線１１２、データ線１１１、データ線１１３を有する。
【００２３】
たとえば、デバイス監視装置１０３＿０は、１つ目の監視対象である共有デバイス１０５＿０に対応する、バス１０４側の制御線１１０＿０、データ線１１１＿０と、共有デバイス１０５＿０側の制御線１１２＿０、データ線１１３＿０を有する。さらに、デバイス監視装置１０３＿０は、２つ目の監視対象である共有デバイス１０５＿１に対応する、バス１０４側の制御線１１０＿１、データ線１１１＿１と、共有デバイス１０５＿１側の制御線１１２＿１、データ線１１３＿１を有する。なお、デバイス監視装置１０３の機能については、図２にて後述する。
【００２４】
共有デバイス１０５＿０、共有デバイス１０５＿３は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃３から利用される周辺デバイスである。具体的には、通信ユニット、カメラデバイス、オーディオデバイス、ディスプレイ、キーボード等である。また、デバイス監視装置１０３に対する監視の優先度が高く設定されている共有デバイス１０５＿２の具体例としては、通信ユニット等が挙げられる。デバイス監視装置１０３に対する監視の優先度が中間に設定されている共有デバイス１０５＿０、共有デバイス１０５＿１の具体例としては、カメラデバイス、オーディオデバイス等が挙げられる。
【００２５】
ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎは、デバイス監視装置１０３からの割込信号を受信する割込入力端子である。また、図１にて図示していないが、ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎは、共有デバイス１０５等からも割込信号を受信する。
【００２６】
ダミーレジスタ１０７＿０〜ダミーレジスタ１０７＿２は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎによる制御レジスタ１０９＿０〜制御レジスタ１０９＿２に対する書き込み情報を保持する。たとえば、ダミーレジスタ１０７＿０は、制御レジスタ１０９＿０に対する書き込み情報を保持する。なお、ダミーレジスタ１０７は、制御レジスタ１０９の何れのビットに対応する書き込み情報を保持してもよいし、制御レジスタ１０９の一部のビットに対応する書き込み情報を保持してもよい。
【００２７】
なお、共有デバイス１０５には、制御レジスタ１０９以外の他のレジスタが存在し、他のレジスタもダミーレジスタ１０７の保持対象としてもよい。他のレジスタとはたとえば、共有デバイス１０５の動作状況が格納されているステータスレジスタ等である。
【００２８】
デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１は、共有デバイス１０５の制御レジスタ１０９に書き込まれた際の応答時間を記憶する記憶領域である。なお、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１の実体は、前述したバス１０４に接続されたＲＡＭ、ＲＯＭ、フラッシュＲＯＭに存在してもよいし、または、デバイス監視装置１０３内に存在する記憶領域に存在してもよい。
【００２９】
続いて、マルチコアプロセッサシステム１００のソフトウェアとしては、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）１２１＃０〜ＯＳ１２１＃ｎ、ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１、アプリ１２３＿０〜アプリ１２３＿５を含む。
【００３０】
ＯＳ１２１＃０〜ＯＳ１２１＃ｎは、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎを制御するソフトウェアである。たとえば、ＯＳ１２１＃０には、アプリ１２３＿０、アプリ１２３＿１のうち、ＣＰＵ１０１＃０に割り当てるアプリを決定するスケジューラや、決定されたアプリをＣＰＵ１０１＃０に割り当てるディスパッチャ等といったソフトウェアが含まれる。また、ＯＳ１２１＃０〜ＯＳ１２１＃ｎは、共有デバイス１０５に対する排他制御処理を行う。
【００３１】
ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１は、ＯＳ１２１＃０〜ＯＳ１２１＃ｎの提供する機能の一つであり、共有デバイス１０５にアクセスするソフトウェアである。ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１は、アプリ１２３＿０〜アプリ１２３＿５からの呼び出しによって活性化し、対応する共有デバイス１０５にアクセスする。
【００３２】
なお、図１では、ドライバ１２２＃０＿０、ドライバ１２２＃１＿０、…、ドライバ１２２＃ｎ＿０が共有デバイス１０５＿０にアクセスするソフトウェアである。同様に、ドライバ１２２＃０＿１、ドライバ１２２＃１＿１、…、ドライバ１２２＃ｎ＿１が共有デバイス１０５＿１にアクセスするソフトウェアである。また図１に図示していないが、共有デバイス１０５＿２、共有デバイス１０５＿３に対するドライバ１２２も、ＯＳ１２１＃０〜ＯＳ１２１＃ｎ内に存在する。
【００３３】
このように、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎがそれぞれのドライバ１２２を呼び出すことで、１つの共有デバイス１０５に対してアクセスできる。同時のアクセスによる不具合を発生させないため、マルチコアプロセッサシステム１００は、排他制御処理によって、１つの共有デバイス１０５に対してアクセスが競合しないように設計されている。
【００３４】
アプリ１２３＿０〜アプリ１２３＿５は、マルチコアプロセッサシステム１００のユーザにサービスを提供するソフトウェア群である。具体的に、アプリ１２３＿０〜アプリ１２３＿５は、音楽再生アプリ、ゲームアプリ、カメラアプリ等である。アプリ１２３＿０〜アプリ１２３＿５は、ドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１を呼び出すことにより、共有デバイス１０５＿０〜共有デバイス１０５＿３を操作する。たとえば、アプリ１２３＿３が音楽再生アプリ、共有デバイス１０５＿１がオーディオデバイスであると想定する。このとき、アプリ１２３＿０は、ドライバ１２２＃１＿１を呼び出して、オーディオデバイスを操作し、音楽再生を実現する。
【００３５】
図２は、デバイス監視装置１０３の機能を示すブロック図である。デバイス監視装置１０３は、設定部２０１＿０、設定部２０１＿１、時差検出部２０２、異常検出部２０３、ＡＣＫ出力部２０４、デバイス制御部２０５、書込部２０６、タイマー２０７を含む。また、デバイス監視装置１０３、共有デバイス１０５は、外部からクロック入力を受けている。
【００３６】
設定部２０１＿０、設定部２０１＿１は、ＣＰＵ１０１＃０〜ＣＰＵ１０１＃ｎのうち、第１ＣＰＵによる共有デバイス１０５へのアクセスに基づいて、タイマー２０７に対しアクセス時間の計測開始を設定する機能を有する。アクセス時間とは、共有デバイス１０５へのアクセス時刻を開始時刻とし、共有デバイス１０５からのアクセスに対する応答信号が発生した時刻を終了時刻とした時間である。
【００３７】
たとえば、設定部２０１＿１は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１に対する書き込み要求を検出し、タイマー２０７に対しアクセス時間の計測開始を設定する。また、設定部２０１＿０、設定部２０１＿１は、共有デバイス１０５から、アクセスに対する応答信号が出力された場合、アクセス時間の計測を停止してもよい。また、応答信号とは、ＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）信号である。なお、設定部２０１＿０は、共有デバイス１０５＿０に対するアクセスを検出し、設定部２０１＿１は、共有デバイス１０５＿１に対するアクセスを検出する。なお、設定された情報は、デバイス監視装置１０３の記憶領域、タイマー２０７の設定レジスタ、などの記憶領域に記憶される。
【００３８】
時差検出部２０２は、アクセス時間が所定時間を超えることを検出する機能を有する。なお、所定時間とは、共有デバイス１０５の仕様となる応答時間であり、デバイス応答時間ＤＢ１０８に格納されている。たとえば、時差検出部２０２は、共有デバイス１０５＿１に対する書き込み要求の時刻を開始時刻とするアクセス時間が共有デバイス１０５＿１の応答時間５００［マイクロ秒］を超えたことを検出する。なお、検出結果は、デバイス監視装置１０３の記憶領域に記憶される。
【００３９】
異常検出部２０３は、時差検出部２０２によってアクセス時間が所定時間を超えたことが検出された場合、検出信号を出力する機能を有する。検出信号としては、ウォッチドッグタイマー１０２に対して異常状態を示す検出信号と、ＩＮＴ端子１０６に対して異常状態を示す検出信号とがある。たとえば、異常検出部２０３は、共有デバイス１０５＿１の仕様となる応答時間５００［マイクロ秒］を超えた場合に、ウォッチドッグタイマー１０２とＩＮＴ端子１０６に対して検出信号を出力する。
【００４０】
ＡＣＫ出力部２０４は、第１のＣＰＵが共有デバイス１０５にアクセス中に、共有デバイス１０５にアクセスしてきた第２のＣＰＵに対し、ダミーＡＣＫ信号を出力する機能を有する。ダミーＡＣＫ信号は、ＡＣＫ信号と同内容の信号である。たとえば、ＡＣＫ出力部２０４は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１にアクセス中に、共有デバイス１０５＿１にアクセスしてきたＣＰＵ１０１＃１に対し、ダミーＡＣＫ信号を出力する。なお、ダミーＡＣＫ信号を出力したという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
【００４１】
デバイス制御部２０５は、第１のＣＰＵに対するアクセスの応答信号がない共有デバイス１０５に対し、リセットの指示を行う機能を有する。たとえば、デバイス制御部２０５は、ＣＰＵ１０１＃ｎに対するアクセスの応答信号がない共有デバイス１０５＿１に対し、リセットの指示を行う。なお、リセットの指示が行われたという情報は、デバイス監視装置１０３の記憶領域に記憶される。
【００４２】
書込部２０６は、デバイス制御部２０５によって共有デバイス１０５がリセット完了した後、ダミーレジスタ１０７の内容を制御レジスタ１０９に書き込む機能を有する。たとえば、書込部２０６は、共有デバイス１０５＿１がリセット完了した後に、ダミーレジスタ１０７＿１の内容を制御レジスタ１０９＿１に書き込む。なお、書き込んだという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
【００４３】
タイマー２０７は、アクセス時間を計測する機能を有する。たとえば、タイマー２０７は、アクセス開始時刻から、外部から入力されたクロックを計数することで、アクセス時間を計測する。また、タイマー２０７は、設定部２０１＿０、設定部２０１＿１によって計測開始、計測停止する。
【００４４】
以下、デバイス監視装置１０３の機能を用いて、図３〜図６にて、マルチコアプロセッサシステム１００が通常運用状態から、異常状態となり、さらに異常状態からの復元動作までの一連の動作について説明を行う。また、図３〜図６では、アプリ１２３＿３を音楽再生アプリと想定し、アプリ１２３＿５を音声が発生するゲームアプリと想定し、共有デバイス１０５＿１をオーディオデバイスと想定する。
【００４５】
図３は、マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。通常運用時におけるマルチコアプロセッサシステム１００は、ＯＳ１２１＃０〜ＯＳ１２１＃ｎがドライバ１２２＃０＿０〜ドライバ１２２＃ｎ＿１を調停、切り替えながら動作している。
【００４６】
具体的には、アプリ１２３＿３は、音楽データのデコードおよびＤＡ変換を行い、変換結果をドライバ１２２＃１＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音楽を再生させている。また、アプリ１２３＿５は、音声データをドライバ１２２＃ｎ＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音声を再生させている。ユーザには、アプリ１２３＿５から発せられる音声データと、アプリ１２３＿３から発せられる音楽データとが合わさった音が聞こえている状態である。
【００４７】
通常運用時におけるデバイス監視装置１０３は、たとえば、ドライバ１２２＃１＿１からの書き込み要求を受けると、制御レジスタ１０９＿１に、書き込み対象のデータを書き込むとともに、対応するダミーレジスタ１０７＿１にも書き込み対象のデータを書き込む。書き込み要求を受けると、設定部２０１＿１は、タイマー２０７による書き込み要求に対応する応答信号が発生するまでのアクセス時間の計測開始を設定する。
【００４８】
図３で示すマルチコアプロセッサシステム１００は通常運用時であるため、共有デバイス１０５＿１は、仕様である応答時間＝５００［マイクロ秒］以内に書き込み要求に対応する応答信号をＣＰＵ１０１＃１に送信する。応答信号となるＡＣＫ信号が共有デバイス１０５＿１から発生すると、設定部２０１＿１は、タイマー２０７によるアクセス時間の計測停止を設定する。
【００４９】
図４は、マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。図４で示すマルチコアプロセッサシステム１００では、アプリ１２３＿５が障害によりストールした状態を示している。障害の内容として、たとえば、アプリ１２３＿５が不正な値をドライバ１２２＃ｎ＿１を経由して共有デバイス１０５＿１に書き込んだ場合である。
【００５０】
このとき、アプリ１２３＿５が、マルチコアプロセッサシステム１００の共有資源である、共有デバイス１０５＿１へのアクセス権を取得したままストールしてしまうことがある。なお、図４の状態では、共有デバイス１０５＿１がハードウェアの障害により故障しているわけではないため、ウォッチドッグタイマー１０２では、ソフトウェアによるデバイスのアクセスにより発生する障害による異常状態を検出することができない。また、ドライバ１２２＃ｎ＿１は、アプリ１２３＿５によってロックされた状態である。
【００５１】
もし、マルチコアプロセッサシステム１００がシングルコアプロセッサシステムであれば、アプリ１２３＿５のストールとともに、ＯＳ１２１がストールすることになる。コアが複数存在するマルチコアプロセッサシステム１００は、ＣＰＵ１０１ごとに独立したＯＳを動作させることにより、ストールの影響を最小限に食い止めることが可能である。しかし、ＣＰＵ１０１＃１上のアプリ１２３＿３が共有デバイス１０５＿１にアクセスを行おうとした場合、応答信号が返らない状態、または、アクセスが行えない状態となる。
【００５２】
本実施の形態にかかるマルチコアプロセッサシステム１００は、このような、応答信号が返らない状態、または、アクセスが行えない状態を防ぐ。初めに、設定部２０１＿１は、アプリ１２３＿５による書き込み時に、タイマー２０７の計測開始を設定する。
【００５３】
図５は、マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。図５で示すマルチコアプロセッサシステム１００は、図４にて計測開始したタイマー２０７の経過時間が、デバイス応答時間ＤＢ１０８で設定されている応答時間＝５００［マイクロ秒］を超えた場合を示している。具体的には、マルチコアプロセッサシステム１００が図４で示す状態にて、アプリ１２３＿５が、音声データＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ、Ｆｉｒｓｔ  Ｏｕｔ）に音声データを書き込み、制御レジスタ１０９＿１にデータセット完了を意味するフラグを設定した場合である。このとき、共有デバイス１０５＿１の仕様として、共有デバイス１０５＿１は、フラグ設定から５００［マイクロ秒］にて受信完了を示すＡＣＫ信号を発行すると定められている場合を想定している。
【００５４】
書き込み要求からの経過時間が５００［マイクロ秒］を超えたことが時差検出部２０２によって検出された場合、異常検出部２０３は、ウォッチドッグタイマー１０２に対してソフトウェアによる周辺デバイスへのアクセスにより発生する障害による異常状態を示す検出信号を出力する。また、異常検出部２０３は、ＩＮＴ端子１０６に対しても、共有デバイス１０５＿１のソフトウェアによる周辺デバイスへのアクセスにより発生する障害による異常状態を示す検出信号を通知する。なお、ＩＮＴ端子１０６から検出信号を受信したＣＰＵ１０１は、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行する。なお、ソフトウェアの検出要求は、ＩＮＴ端子１０６＃０〜ＩＮＴ端子１０６＃ｎにブロードキャスト送信してもよいし、アクセスを行ったＣＰＵ１０１＃１に対するＩＮＴ端子１０６＃１のみに送信してもよい。
【００５５】
また、ＣＰＵ１０１＃１に応答信号が返らない状態である場合、ＡＣＫ出力部２０４が、ダミーＡＣＫ信号をＣＰＵ１０１＃１に送信し、アプリ１２３＿３の停止を防ぐ。従来例にかかるマルチコアプロセッサシステム１００では、ＡＣＫ信号が返らずにＯＳ１２１がタイムアウトを検出し、アプリ１２３＿３を異常終了するという対応が取られていた。しかし、ＯＳ１２１によるタイムアウトが数秒かかる場合や、または、ＯＳ１２１がタイムアウトせずに、ストールする場合も存在していた。本実施の形態にかかるマルチコアプロセッサシステム１００では、ダミーＡＣＫ信号を送信することで、アプリ１２３＿３の異常終了を避けることができる。
【００５６】
図６は、マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。図６で示すマルチコアプロセッサシステム１００は、図５にて異常検出部２０３、ＡＣＫ出力部２０４が動作した後である。図５にてソフトウェアによる周辺デバイスへのアクセスにより発生する障害による異常状態の通知を受けたウォッチドッグタイマー１０２が、ＣＰＵ１０１＃ｎのウォームスタート要求として検出信号を通知する。ウォームスタート要求である検出信号を受信したＣＰＵ１０１＃ｎはソフトリセットが行われる。また、ドライバ１２２＃ｎ＿１は、ウォッチドッグタイマー１０２によって検出信号を受信したＯＳ１２１＃ｎのウォームスタートにより、ロックが解除され、共有デバイス１０５＿１へのアクセス権を解放する。
【００５７】
また、ＩＮＴ端子１０６＃ｎから検出信号を受信したＣＰＵ１０１＃ｎは、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行し、アプリ１２３＿５を検出する。検出後、ＣＰＵ１０１＃ｎは、検出されたアプリ１２３＿５を強制終了させる。
【００５８】
また、デバイス制御部２０５が共有デバイス１０５＿１に対して、リセットを行った後に、書込部２０６がダミーレジスタ１０７＿１に書き込まれていたデータを制御レジスタ１０９＿１に書き込む。以上の動作により、マルチコアプロセッサシステム１００は、異常状態から復旧することになる。問題のあったアプリ１２３＿５が強制終了し、アプリ１２３＿３については正常に処理を続行することができる。
【００５９】
図７は、デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。デバイス応答時間ＤＢ１０８は、デバイス名、応答時間という２つのフィールドを含む。デバイス名フィールドには、共有デバイス１０５の名称が格納される。また、共有デバイス１０５が一意に特定できるＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）であってもよい。応答時間フィールドには、共有デバイス１０５の応答時間が格納される。
【００６０】
たとえば、監視の優先度が中間の共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿０には、共有デバイス１０５＿０、共有デバイス１０５＿１の応答時間が、それぞれ、４００［マイクロ秒］、５００［マイクロ秒］、と格納されている。また、監視の優先度が高い共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿１には、共有デバイス１０５＿２の応答時間が、１０［ミリ秒］と格納されている。また、応答時間フィールドに関しては、ユーザによって自由に変更されてもよい。
【００６１】
図２で示したデバイス監視装置１０３の機能、および図７で示したデバイス応答時間ＤＢ１０８の記憶内容に基づいて、デバイス監視装置１０３は、異常状態からの復元処理を行う。図８、図９にて、デバイス監視装置１０３は、異常状態を検出し、続けて復元処理のフローチャートを示す。
【００６２】
また、図８、図９で示すフローチャートでは、アプリ１２３＿５の共有デバイス１０５＿１に対する書き込み要求によって、アプリ１２３＿５がストールし、その後、アプリ１２３＿３が共有デバイス１０５＿１に対して書き込み要求を行うことを想定する。また、アプリ１２３＿５、ドライバ１２２＃ｎ＿１は、ＣＰＵ１０１＃ｎによって実行され、アプリ１２３＿３は、ＣＰＵ１０１＃１によって実行される。なお、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出すが、図８、図９では、ドライバ１２２＃１＿１の処理については、ドライバ１２２＃ｎ＿１と等しいため、図示せず、ドライバ１２２＃ｎ＿１の処理番号を引用して説明する。
【００６３】
図８は、マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。アプリ１２３＿５は、ドライバ１２２＃ｎ＿１をオープンする（ステップＳ８０１）。オープンされたドライバ１２２＃ｎ＿１は、共有デバイス１０５＿１に対するアクセス権を取得する（ステップＳ８０２）。続けて、ドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１の退避・復元を行う（ステップＳ８０３）。
【００６４】
制御レジスタ１０９＿１の退避・復元が行われた後、アプリ１２３＿５は、ドライバ１２２＃ｎ＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８０４）。呼び出されたドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１に書き込み要求を行う（ステップＳ８０５）。
【００６５】
書き込み要求を受信したデバイス監視装置１０３＿０は、設定部２０１＿１によって、タイマー２０７の計測開始を設定する（ステップＳ８０６）。続けて、デバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１と制御レジスタ１０９＿１に書き込み要求となるデータを書き込む（ステップＳ８０７）。
【００６６】
書き込み要求後、アプリ１２３＿５は、異常発生を検出したかを判断する（ステップＳ８０８）。異常が発生した場合（ステップＳ８０８：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリ可能か否かを判断する（ステップＳ８０９）。ソフトウェアリカバリ可能である場合（ステップＳ８０９：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリを実行する（ステップＳ８１０）。ソフトウェアリカバリ不可能である場合（ステップＳ８０９：Ｎｏ）、アプリ１２３＿５は、異常状態となり（ステップＳ８１１）、以後、アプリ１２３＿５はストールした状態となる。
【００６７】
異常発生を検出していない場合（ステップＳ８０８：Ｎｏ）、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。なお、ステップＳ８０８：Ｎｏとなった場合、共有デバイス１０５＿１よりＡＣＫ信号が送られるため、ステップＳ８０６で設定されたタイマー２０７の計測が停止する。ステップＳ８１０実行後も、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。
【００６８】
続けて、アプリ１２３＿５がストール中にアプリ１２３＿３による共有デバイス１０５＿１へのアクセスが行われる場合を想定する。アプリ１２３＿３は、ドライバ１２２＃１＿１をオープンする（ステップＳ８１２）。ステップＳ８１２の処理後、ドライバ１２２＃１＿１が実行されるが、ステップＳ８１２の処理後のドライバ１２２＃１＿１の処理は、ステップＳ８０２、ステップＳ８０３の処理と等しい。しかしながら、アプリ１２３＿５が共有デバイス１０５＿１に対するアクセス権を有したままストールしたために、アプリ１２３＿３は、共有デバイス１０５＿１に対するアクセス権を取得できない。したがって、ドライバ１２２＃１＿１は、ステップＳ８０３の処理である、制御レジスタ１０９＿１の退避・復元を完了できず、失敗することになる。
【００６９】
続けて、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８１３）。ステップＳ８１３の処理後、ドライバ１２２＃１＿１が実行され、処理としては、ステップＳ８０５の処理と同内容の処理が実行される。
【００７０】
ドライバ１２２＃１＿１より制御レジスタ１０９＿１への書き込み要求を受けたデバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１に書き込む（ステップＳ８１４）。なお、ステップＳ８１４の処理にて、アプリ１２３＿３は共有デバイス１０５＿１に対するアクセス権を有していないため、制御レジスタ１０９＿１に書き込み要求が反映されない。
【００７１】
図９は、マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。デバイス監視装置１０３＿０は、時差検出部２０２によって、タイマー２０７の計測によるアクセス時間が応答時間を超えたことを検出し、異常状態として検出する（ステップＳ９０１）。異常状態を検出後、デバイス監視装置１０３＿０は、ＡＣＫ出力部２０４によって、ダミーＡＣＫ信号をＣＰＵ１０１＃１に出力する（ステップＳ９０２）。ダミーＡＣＫ信号を受けたＣＰＵ１０１＃１は、アプリ１２３＿３を正常実行する（ステップＳ９０３）。
【００７２】
また、異常状態を検出後、デバイス監視装置１０３＿０は、異常検出部２０３によって、検出信号をウォッチドッグタイマー１０２とＩＮＴ端子１０６に出力する（ステップＳ９０４）。
【００７３】
ＩＮＴ端子１０６＃ｎより、検出信号を受信したＣＰＵ１０１＃ｎが、アプリ１２３＿５を強制終了する（ステップＳ９０５）。また、ドライバ１２２＃ｎ＿１は、ウォッチドッグタイマー１０２によって検出信号を受信したＯＳ１２１＃ｎのウォームスタートにより、共有デバイス１０５＿１に対するアクセス権を解放する（ステップＳ９０６）。
【００７４】
続けて、デバイス監視装置１０３＿０は、異常検出部２０３によって、ダミーレジスタ１０７＿１に対する書き込みを禁止する（ステップＳ９０７）。書き込み禁止後、デバイス監視装置１０３は、デバイス制御部２０５によって、共有デバイス１０５＿１に対してリセットの指示を行う（ステップＳ９０８）。共有デバイス１０５＿１のリセット完了後、デバイス監視装置１０３＿０は、書込部２０６によって、ダミーレジスタ１０７＿１の内容を、制御レジスタ１０９＿１に書き込む（ステップＳ９０９）。書き込み後、デバイス監視装置１０３＿０は、ダミーレジスタ１０７に対する書き込み禁止を解除する（ステップＳ９１０）。
【００７５】
なお、図８、図９に示したフローチャートでは、問題のあるアプリ１２３＿５がストールした後、問題のないアプリ１２３＿３が共有デバイス１０５＿１にアクセスしている。もし、問題のあるアプリ１２３＿５がストールした後に、何れのアプリも共有デバイス１０５＿１にアクセスしない場合でも、マルチコアプロセッサシステム１００は、異常状態を復元することができる。何れのアプリも共有デバイス１０５＿１にアクセスしない場合、デバイス監視装置１０３＿０は、ステップＳ８１４、ステップＳ９０２、ステップＳ９０９の処理を行わない。
【００７６】
以上説明したように、アクセス方法、およびマルチコアプロセッサシステムによれば、ＣＰＵからドライバによるアクセス開始時刻以後、応答信号が返らずに所定時間が経過した場合、デバイス監視装置が共有デバイスの異常状態として検出信号を出力する。これにより、マルチコアプロセッサシステムは、ドライバが共有デバイスへのアクセスによって発生するストールを検出できる。
【００７７】
また、デバイス監視装置は、所定時間について、共有デバイスの仕様となる応答時間を格納するメモリから参照してもよい。これにより、マルチコアプロセッサシステムは、応答時間の異なる共有デバイスの動作に合わせて、異常状態を検出できる。また、マルチコアプロセッサシステムは、ユーザの指示等により、所定時間を変更してもよい。
【００７８】
また、デバイス監視装置は、共有デバイスからアクセスに対する応答信号が出力される場合には、所定時間とアクセス開始時刻からのアクセス時間との比較を停止する。これにより、マルチコアプロセッサシステムは、共有デバイスが正常に動作している場合に異常状態として検出してしまうことがないようにできる。
【００７９】
また、デバイス監視装置は、ＣＰＵから共有デバイスに対して書き込まれるデータを保持する記憶領域を有し、異常状態を検出した場合に、記憶領域に対する保持を禁止してもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスに書き込まれなかったデータを、他のＣＰＵ等からによる上書きから保護することができる。
【００８０】
また、デバイス監視装置は、異常状態を検出する前に記憶領域に書き込まれたデータを、異常検出後も保持していてもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスの制御レジスタに書き込まれなかったデータを保持することができる。
【００８１】
また、デバイス監視装置は、検出信号に基づいてドライバがリセットされた後、記憶領域に保持していたデータを、共有デバイスの制御レジスタに書き込んでもよい。これにより、マルチコアプロセッサシステムは、異常状態から復元でき、異常状態を発生させたアプリとは異なる、問題のないアプリによって発生したデータを、共有デバイスに書き込ませることができる。
【００８２】
また、デバイス監視装置は、記憶領域に保持していたデータを共有デバイスに書き込んだ後、異常状態を発生させたアプリを実行していたＣＰＵとは異なる他のＣＰＵによって実行される別のアプリからの共有デバイスへのアクセスを受け付けてもよい。これにより、マルチコアプロセッサシステムは、別のアプリがストールすることがなく、ストールが連鎖的に発生することを避けることができる。
【００８３】
また、従来例にかかるマルチコアプロセッサシステムでは、ＯＳがアプリからの応答がないことを異常状態として検出していた。この場合、異常状態として検出できるまでに数秒かかってしまうため、ストールの連鎖が発生してしまい、また、ユーザの利便性が下がるといった問題があった。本実施の形態にかかるマルチコアプロセッサシステムでは、共有デバイスの応答時間という、短い時間で異常状態を検出できるため、ストールの連鎖が発生する前に異常状態を検出できるうえ、ユーザにも異常状態が発生したことを気づかれにくいという効果がある。
【００８４】
また、従来例にかかるマルチコアプロセッサシステムでは、ストールが連鎖的に発生した場合に、ユーザが装置の故障と錯覚する可能性がある。錯覚した結果、設計者等が故障に対する対応が発生するという問題があった。装置の故障となった場合、故障の点検のために装置を回収することになり、対応にかかるコストが大きくなるという問題もあった。また、ソフトウェアによる異常発生は、様々な条件が重なったときに発生することもあり、異常状態の再現が困難であるという問題もあった。
【００８５】
しかし、本実施の形態にかかるマルチコアプロセッサシステムでは、問題のあるアプリが強制終了し、他のアプリは正常実行するために、ユーザは装置の故障と錯覚せずにアプリに問題があるということを容易に判断できる。これにより、障害のレポートがあった場合、装置の回収をしなくてもよく、開発者は問題のあるアプリの再配布を行うことで対応できるため、マルチコアプロセッサシステは、対応にかかるコストを小さくすることができる。
【００８６】
また、本実施の形態で説明したデバイス監視装置１０３は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したデバイス監視装置１０３の機能（設定部２０１〜タイマー２０７）をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、デバイス監視装置１０３を製造することができる。
【符号の説明】
【００８７】
１０２  ウォッチドッグタイマー
１０３  デバイス監視装置
１０５  共有デバイス
１０７  ダミーレジスタ
１０８  デバイス応答時間ＤＢ
１０９  制御レジスタ
１１０、１１２  制御線
１１１、１１３  データ線
２０１  設定部
２０２  時差検出部
２０３  異常検出部
２０４  ＡＣＫ出力部
２０５  デバイス制御部
２０６  書込部
２０７  タイマー
【国際調査報告】
2012066622.tif 000012
2012066622.tif 000013