JP2018092571A - 電子装置、再起動方法およびプログラム - Google Patents

Abstract

【課題】異常検出のためにウォッチドッグ・タイマを利用せずＯＳおよびアプリケーション・プログラムといったソフトウェアの暴走やストールなどを監視し、電子装置を効率的に再起動させることのできる電子装置、再起動方法およびプログラムを提供する。【解決手段】電子装置は複数のコアを有するＣＰＵ１０１を備える。ＣＰＵには、コアの異常を能動的に監視する能動的監視手段を備えるコア２０１と、コアの異常を受動的に監視する受動的監視手段を備えるコア２０２が実装されており、互いに相互監視を実行する。能動的監視手段または受動的監視手段のいずれか１つがコアの異常を検出することに応答して、ＣＰＵを再起動させる事により、効率的なＣＰＵの再起動を可能としている。【選択図】図２

Description

本発明は、電子装置、再起動方法およびプログラムに関する。

フェール・セーフが重要視されるコンピュータ・システムにおいて、ソフトウェアの暴走やストールなどのエラーが発生した場合、システムを可能な限り安全に停止した後、自動的に再起動してダウンタイムを短くすることが要求されている。

このような自動的な再稼働を可能とする処理は、ミッション・クリティカルなサーバ分野ばかりでなく、それ以外にも、機器が正常に稼働できなくなると機器の性能を大きく左右することになる車積機器、パチンコ／パチスロなど、ユーザが視点を離さない遊技機、ネットワーク・ゲームの分野にも用いられてきている。

これまでにも、ソフトウェアの異常状態を察知して自動的に再起動するための様々な機構が考案され、異常状態から自動的に回復するための技術が知られている。例えば従来から、ソフトウェア異常検出をウォッチドッグ・タイマの発動をトリガにしてシステムの暴走を察知する技術が知られている。しかしながらこの技術を、ウォッチドック・タイマが利用できないシステムで同様の機構を実現しようとすると、エラーを発生した計算装置とは別に、異常検出を行う機器を設置する必要が有るという不都合が発生する。

また、ＣＰＵ上で動作するソフトウェアには、オペレーティング・システム（ＯＳ）の他、アプリケーション・プログラムも存在する。アプリケーション・プログラムは、各種の例外違反を発生させ、コア・ダンプを生じさせることもある。その他、近年のプログラミング技術においては、例えばパイプライン処理や投機的命令実行などのように複数のプロセスを並列的に実行させ、各処理が効率的に処理結果を利用して効率的に処理を完了させるコーディングが使用される場合が多い。

このような態様においては、ＣＰＵの不正終了などを生じさせるには至らないものの、将来的に見ればアプリケーション・プログラムの正常動作を害するアプリケーション・プログラムの実行状態も想定される。例えば、正常動作を害するアプリケーション・プログラムの実行状態を生じさせる原因としては、スケジューリング違反、メモリ保護違反、排他制御違反などを挙げることができる。このような場合には、ＣＰＵコア自体は、不具合なく動作していたとしても、将来的には、正常な終了が害される。

アプリケーション・レベルでの実行時の不具合が発生した場合、例えば組み込みシステムの場合では、不具合を発生したＣＰＵを直ちにリセットすると、ＣＰＵの内部状態とは関係なく動作している外部機器に影響を与えることになる。このため、ＯＳ自体のストールの他、アプリケーション・プログラムの不具合が発生した場合にでも、適切にシステムをリセットすることが必要とされていた。

この他、特開２０１３−１４９１２８号公報（特許文献１）には、システムの障害(含ソフトウェアの異常)を発見する目的で、専用の診断プロセッサを設ける方法が記載されている。特許文献１では、診断プロセッサは、ウォッチドッグ・タイマの発動を待たずに電源制御部に対して再起動要求を発行し、より速やかにシステムの再起動を実施して、システムを保護する。しかしながら、特許文献１に記載された技術は、専用プロセッサを追加しないと機能しないという問題は解消できていない。

本発明は、異常検出のためにウォッチドッグ・タイマを利用せず、システムに余分なＣＰＵを追加することなく、ＯＳおよびアプリケーション・プログラムといったソフトウェアの暴走やストールなどを監視し、電子装置を効率的に再起動させることを目的とする。

本発明によれば、
複数のコアを有するＣＰＵを備える電子装置であって、
前記複数のコアのうち第１のコア内に設けられ、前記複数のコアのうちの前記第１のコア以外の第２のコアの異常を能動的に監視する能動的監視手段と、
前記複数のコアのうち第２のコア内に設けられ、前記第１のコアの異常を前記コアの異常を受動的に監視する受動的監視手段と、
前記能動的監視手段または前記受動的監視手段のいずれか１つが前記コアの異常を検出することに応答して前記ＣＰＵを再起動させる手段と
を備える電子装置が提供される。

本発明によれば、異常検出のためにウォッチドッグ・タイマを利用せず、システムに余分なＣＰＵを追加することなくソフトウェアの暴走やストールなどを監視し、電子装置を効率的に再起動させることが可能となる。

本実施形態の電子装置１００のハードウェア・ブロックを示す図。 本実施形態のＣＰＵ１０１の例示的な内部構造を示すブロックダイアグラム。 本実施形態のＣＰＵ１０１のソフトウェア・ブロック３００を示す図。 本実施形態のＣＰＵ１０１の再起動方法のフローチャート。 本実施形態のエラー・チェック処理のシーケンス図。 能動的監視手段であるチェッカ２に異常が発生した場合のエラー・チェック処理のシーケンス図。 図６とは逆に受動的監視手段であるチェッカ１に異常が発生した場合のエラー・チェック処理のシーケンス図。 本実施形態のＣＰＵ１０１が２コアではなく、４コアの場合の実施形態を示す図。 本実施形態の実行リスト９００を示す図。 本実施形態の実行リスト１０００を示す図。 第２の実施形態のＣＰＵ１０１の再起動方法のフローチャート。 コア２０２が実行するアプリケーションに異常が発生した場合のエラー・チェック処理のシーケンス図。 コア２０１が実行するアプリケーションに異常が発生した場合のエラー・チェック処理のシーケンス図。 本実施形態のＣＰＵ１０１が２コアではなく、４コアの場合の実施形態を示す図。 第３の実施形態のコア２０２が実行するアプリケーションに異常が発生した場合のエラー・チェック処理のシーケンス図。

＜第１の実施形態＞
以下、本発明について実施形態を以て説明するが本発明は、後述する実施形態に限定されるものではない。図１は、本実施形態の電子装置１００のハードウェア・ブロックを示す。図１に示す電子装置１００は、情報処理装置、画像形成装置、組込装置、車載装置、その他、ＬＳＩを使用して電子・電気的に動作可能な装置であるものとして説明する。本実施形態の電子装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３およびＮＶＲＡＭ１０４を含んでいる。

ＣＰＵ１０１は、本実施形態ではマルチコア・プロセッサであり、ＣＰＵコアごとに独立したオペレーティング・システムの下、複数のプログラムを並列実行する。ＲＡＭ１０２は、オペレーティング・システム（ＯＳ）といったプログラムを読み込んで、ＣＰＵ１０１が各種プログラムを実行するために必要な実行空間を提供する。その他、ＲＡＭ１０２は、ＣＰＵ１０１がプログラムを実行するためのデータなどを格納する実行時記憶空間を提供することができる。

ＲＯＭ１０３は、ＢＩＯＳ（Basic Input Output System)、ブートストラップ（Bootstrap）プログラム、その他、ＣＰＵ１０１が機能を提供するためのプログラムを記憶しており、ＣＰＵ１０１の起動時および本実施形態に従い、ＣＰＵコアのエラーやストール時にＣＰＵ１０１がプログラムを読み込んで、ハードウェアの初期設定、ＯＳ起動、コアチェッカなどの機能を実現可能としている。以上のハードウェア・ブロックは、システムバス１０６により相互接続されていて、システム・クロックに従ってその動作が制御されている。

電子装置１００は、さらにＮＶＲＡＭ１０４および通信装置１０５を含んでいる。ＮＶＲＡＭ１０４は、例えば電子装置１００のＣＰＵ１０１がエラーやストールしたときに再起動される場合、再起動直前のＣＰＵデータ、例えば、各種データ、プログラムカウンタ、レジスタ構成などを格納する機能を提供することができる。ＣＰＵ１０１がエラーなどによって再起動される場合、本実施形態では、ＣＰＵ１０１は、例えばＮＶＲＡＭ１０４に退避させたデータを使用して効率的に再起動前の計算環境を再現する構成とすることができる。

また電子装置１００が備える通信装置１０５は、例えばＮＩＣ（ネットワーク・インタフェース・カード）を含んで実装することができ、イーサネット（登録商標）、ＩＥＥＥ８０２．ｘ、ＬＴＥ、Ｗｉｆｉその他の通信基盤を使用して電子装置１００を、例えばインターネットなどの他のシステムに接続することを可能とする。

さらに電子装置１００は、システムバス１０６に接続されたエラー検知部１０８を備える。当該エラー検知部１０８は、ＣＰＵ１０１のコアがエラーまたはストールしたときに発生する例外を処理する機能を提供し、例えば割り込みハンドラの１機能として実装することができる。エラー検知部１０８の出力は、電源（ＰＳＵ）１１２に入力され、本実施形態に従い、ＣＰＵ１０１がエラーやストールしたと判断された場合、電源１１２を再起動させる機能を有する。電源１１２が再起動される場合には、ＣＰＵ１０１は、設定されたＰＯＳＴ機能、ブートストラップ・プロトコルに従ってＣＰＵ１０１のコアを初期設定し、ＯＳの起動、コアチェッカの起動および各種アプリケーションの起動などを可能とする。

その他、電子装置１００は、ＰＣＩｅといった周辺バスを介して接続された表示装置１０９、記憶装置１１０および入力装置１１１を含んで構成することができる。表示装置１０９は、液晶ディスプレイ装置、タッチパネルその他のユーザインタフェースを提供する機能を、ＶＧＡ、ＸＧＡ、ＨＤＭＩ（登録商標）といった規格を使用して提供する。

記憶装置１１０は、ハードディスク・ドライブやＳＳＤを含んで構成することができ、例えばＡＴＡ、ＳＡＴＡ、ＵＳＢなどの通信プロトコルを使用して、記憶装置１１０が記憶したＯＳ、ドライバ、アプリケーションの実行ファイルを、ＣＰＵ１０１が高速に利用するためにＣＰＵ１０１による読み出しを可能とする。

入力装置１１１は、キーボード、マウス、ジョイスティックを使用することができ、電子装置１００に対して外部から情報や指令を入力するために使用される。なお、タップやスワイプなどを可能とするタッチパネルは、表示装置１０９および入力装置１１１の機能を両方具備する機能手段である。

本実施形態で使用するＣＰＵ１０１は、マルチコア・プロセッサとすることができ、例えば、ＰＥＮＴＩＵＭ（登録商標）ＤＵＡＬ ＣＯＲＥ(登録商標）、ＣＯＲＥ２ ＤＵＯ（登録商標）、ＣＯＲＥ２ ＱＵＡＤ（登録商標）、ＣＥＬＥＲＯＮ（登録商標） ＤＵＡＬ ＣＯＲＥ、ＡＴＯＭ(登録商標）、ＣＯＲＥ２ＤＵＯ（登録商標）、ＣＯＲＥ２ＱＵＡＤ（登録商標）、ＣＯＲＥｉ（登録商標）シリーズなどの他、ＸＥＯＮ(登録商標）、マルチコア構成を備えるＰＥＮＴＩＵＭ（登録商標）互換ＣＰＵ、ＰＯＷＥＲ ＰＣ（登録商標）、いわゆるＧＰＵとしてとして参照されるＣＰＵなどを挙げることができるがこれらに限定されるものではない。この他にも、特定用途や組込制御のために使用される、ＳＨシリーズ（Ｒｅｎｅｓａｓ）、ＯＭＡＰファミリ（Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ）その他のマルチコアＣＰＵを使用することができる。

ＮＩＣ（ネットワークインタフェース・カード）１１０は、ネットワーク１１３へと画像形成装置１２０を接続させることで、ウェブ・サーバ、ストレージ・サーバ、認証サーバ、クラウド・サーバといった外部装置との情報通信を可能としている。本実施形態のネットワーク１１３は、イーサネット（登録商標）、ＦＴＨ、ＩＥＥＥ８０２．ｘなどの有線または無線プロトコルを使用してＬＡＮ、インターネットを適宜含んで構成することができ、特に通信プロトコルには限定はない。

使用するオペレーティング・システム（ＯＳ）としては、ＷｉｎｄｏｗｓＳｅｒｖｅｒ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）、ＯＰＥＮＢＳＤ、ＣｅｎｔＯＳ、Ｕｂｎｔｕ、ｅＴ−Ｋｅｒｎｅｌなどリアルタイム系ＯＳ、Ｍｏｎｔａｖｉｓｔａ Ｌｉｎｕｘ（登録商標） ＣＧＥ、ＰＯＳＩＸ１００３．１ｂ、ＯＳＥＫ、ＩＴＲＯＮまたはそれ以外の適切なＯＳを挙げることができる。さらに、ＣＰＵ１０１は、上述したＯＳ上で動作する、アセンブラ言語、Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎなどのプログラミング言語により記述されたアプリケーション・プログラムを格納し、実行することができる。

図２は、本実施形態のＣＰＵ１０１の例示的な内部構造を示すブロックダイアグラムである。ＣＰＵ１０１は、図２に示した実施形態では、コア２０１、コア２０２を搭載する２コアＣＰＵアーキテクチャとして実装されている。コア２０１を以下、コア１として参照し、コア２０２を以下、コア２として参照する。各コア１、２は、ＣＰＵ１０１内部を相互接続する内部バス２０３を介して相互接続されており、相互の情報が利用可能とされている。

さらに内部バス２０３には、割り込み入力２０９から送付されるコア１に対する割り込みを制御する割り込みハンドラＩＲＱＨ１２０４、コア２に対する割り込みを制御する割り込みハンドラＩＲＱＨ２０６を備える。また、ＩＲＱＨ２０４、２０６は、コア１、コア２に対する共通の割り込みも制御し、コア１およびコア２の異常を外部に通知し、ＣＰＵ１０１を再起動するための手段としても機能する。

さらにＣＰＵ１０１は、通信部２０５を備えており、通信部２０５は、本実施形態のコア間通信手段を構成し、内部バス２０３を介してコア１、コア２間のコア間通信を可能とさせている。なお、ＣＰＵ１０１の異常を外部に通知するための手段は、割り込み信号ではなく、ＣＰＵ１０１のデータピンを介した信号とすることもできる。

通信部２０５は、メッセージ、宛先アドレス、送信元アドレスを含む情報をコア１またはコア２から受け取り、割り込みライン２０７、２０８を介して送信先のコア１または２にメッセージを取得させる機能を提供し、コア間通信を実現させている。なお、本実施形態のＣＰＵ１０１を構成するコア数は、２に限定されず、４コア、８コア、１６コアなど、要求される特性に従い、適宜使用することができる。

図３は、本実施形態のＣＰＵ１０１のソフトウェア・ブロック３００を示す。各ソフトウェア・ブロックは、ＣＰＵ１０１の各コアがＲＡＭ、ＲＯＭといったに各ソフトウェアを読み込んで、ＣＰＵ１０１のコア内に実行コードを展開することにより、ＣＰＵ１０１上に実現される機能ブロックである。コア２０１には、ＯＳ１がインストールされ、ＯＳ１上で、本実施形態のチェッカ・プログラム１（以下チェッカ１として参照する。）および他のアプリケーション・プログラム１〜４，．．．が動作している。

またコア２０２においては、ＯＳ２がインストールされており、ＯＳ２上で、チェッカ２およびアプリケーション・プログラム１０〜１３，．．．が動作している。なお、ＯＳ１と、ＯＳ２は、同一でも異なっていても良く、例えばＯＳ１は、ＵＭＩＸ（登録商標）とすることができ、ＯＳ２は、リアルタイム系ＯＳとして実装することができ、これらの組み合わせに特に限定はない。例えばこれに限定されるものではないが、コア２０１が本実施形態における第１のコアに相当し、コア２０２が本実施形態の第２のコアに相当する。

本実施形態においては、チェッカ１およびチェッカ２がコア１、２の相互監視を実行する機能を提供する。例えば、本実施形態において、コア２０１のチェッカ１は、能動的にコア２０２のチェッカ２の動作をチェックする能動的監視手段として機能する。例えば、チェッカ１は、定期的にコア２のチェッカ２に対してメッセージをポーリングする機能を有する。一方、コア２０２のチェッカ２は、チェッカ１からのポーリングを受けた場合にだけ、チェッカ１に対して応答する機能を有する。また、チェッカ２は、チェッカ１からのポーリングの間隔をモニタする機能を提供し、コア１からのポーリングがないことを受動的に判断して、コア１に対する受動的監視手段を構成する。

すなわち、本実施形態では、各コアにそれぞれ１のチェッカを実装する。そして、各コアのうち１のチェッカ、例えばチェッカ１を他のコアに対する能動的監視手段として機能させる。チェッカ１は、ポーリングの結果、ポーリング先からの応答をモニタしており、応答が第１所定期間、例えば合計５〜１０秒ないと、ポーリング先のコアがエラーまたはストールしたものと判定する機能を有する。

これに対してコア２のチェッカ２は、説明する実施形態ではコア１に対する受動的監視として機能する。より具体的には、チェッカ２は、コア１からのポーリング・メッセージを第２所定期間にわたり受領しない場合、チェッカ１、すなわちコア１がエラーまたはストールしたものと判断する。

本実施形態で、コア１またはコア２のいずれかがエラーまたはストールした場合には、エラーまたはストールしていない側のコアがエラー発生割り込みを生成し、エラー検知部１０８に通知する。エラー検知部１０８は、当該割り込みを検知すると、電源１１２をリセットしてＣＰＵ１０１の再起動を開始させる。

なお、コア１およびコア２が共にエラーまたはストールする場合も想定できるが、本実施形態では、コア１およびコア２は独立したＯＳの下で独立した処理を行うものとして説明するので、同時的なエラーまたはストールは、ＣＰＵ１０１自体の機能不全の他、発生しないものとして説明する。

図４は、本実施形態のＣＰＵ１０１の再起動方法のフローチャートを示す。図４の処理は、ステップＳ４００から開始し、Ｓ４０１〜Ｓ４０５およびＳ４０１ａ〜Ｓ４０５のコア数に対応した並列のステップを含んで実行される。しかしながら、ステップＳ４０５のリセット処理は、少なくとも１のコアがエラーまたはストールしたと健全なコアが判定した段階で実行される。

上述したように、図４の処理はコア数に対応して並列に実行されるので、コア１に対応するステップＳ４０１〜Ｓ４０５のみを説明し、他の処理は省略する。ステップＳ４０１では、ブートストラップ・プロトコルに従い、ＰＯＳＴチェックなどを実行した後ＯＳ１をブートする。ステップＳ４０２では、チェッカ１プログラムをロードし、チェッカ１を起動する。その後、ステップＳ４０３で各アプリケーション・プログラムを起動し、コア１のサービスを開始する。

ステップＳ４０４では、他のコアにエラーが発生したか否かを判断し、エラーが発生した場合（ｙｅｓ）処理をステップＳ４０５に分岐させ処理をステップＳ４０１およびＳ４０１ａに戻し、ブートストラップ処理から再起動処理を開始させる。一方、エラーが発生していない場合（ｎｏ）、ステップＳ４０４で継続してエラーの発生をチェックする。以下、図５〜図７を使用して本実施形態のステップＳ４０４におけるエラー・チェック処理を説明する。

図５は、本実施形態のエラー・チェック処理のシーケンス図である。図５中、チェッカ２が、能動的監視手段であり、チェッカ１が受動的監視手段であるものとして説明を行う。チェッカ２は、ステップＳ５００でチェッカ１に対してポーリングを行う。当該ポーリングを受領したチェッカ１は、ステップＳ５０１で、応答を返す。

当該応答を受領したチェッカ２は、ステップＳ５０２で応答なしカウンタをクリアする。そしてチェッカ１側では、ステップＳ５０３でチェックなしカウンタをクリアした後再カウントを開始する。この一連の処理で、ステップＳ５０２、Ｓ５０３からチェックの時間軸がリセットされる。

チェッカ２は、ステップＳ５０４で新たな時間軸に沿って応答を待機し、ステップＳ５０５で、ポーリング・タイミングの到来によりチェッカ１に対してポーリングを行う。当該ポーリングを受領したチェッカ１は、ステップＳ５０６で応答を返す。その後、チェッカ２は、ステップＳＤ５０７およびＳ５０９で、後続する時間軸におけるチェックを継続し、そしてチェッカ１側では、ステップＳ５０３でチェックなしカウンタをクリアした後再カウントを開始する。

図５の処理は、コア１およびコア２にエラーやストールが発生するまで継続される。図６、図７を使用してコアにエラーやストールが発生した場合の処理を説明する。図６は、能動的監視手段であるチェッカ２にエラー、ストールといった異常が、ステップＳ６００で発生したものとする。チェッカ２を実装するコア２は、その後、機能不全となっている。

受動的監視手段であるチェッカ１は、ステップＳ６０１でチェックなしタイマを起動し、ステップＳ６０２でチェック無しタイマのカウントアップ（またはカウントダウン）を実行する。ステップＳ６０３でチェック無しカウンタが満了すると、ステップＳ６０４でチェック無しカウンタをリセットし、チェック無しの累積期間を、ステップＳ６０１〜Ｓ６０３を反復して計時する。なお、累積期間および反復回数は、電子装置１００の制御するべき機器の必要に応じて設定することができ、累積期間としては例えば数１００ｍｓ〜数１０ｓ、好ましくは１ｓ〜１０ｓ程度とすることができるが、これらの期間に限定されるわけではない。

チェッカ１は、その後所定の期間、カウントを反復し、チェッカ２からのポーリングが途絶えた期間について設定した累積期間がステップＳ６０７で満了すると、ステップＳ６０８で終了処理を開始する。ステップＳ６０８の終了処理には、例えば、コアの状態をＮＶＲＡＭ１０４に退避させる処理、ハードディスク装置の回転停止処理その他の処理を挙げることができる。チェッカ１のコアは、ステップＳ６０８の処理を完了すると、エラー信号を生成し、ステップＳ６０９で再起動処理を開始させる。

以上の処理により、能動的監視手段が機能不全となった場合にでも、受動的監視手段単独でコアの機能不全をチェックすることが可能となる。

図７は、図６とは逆に受動的監視手段であるチェッカ１に異常が発生した場合のエラー・チェック処理のシーケンス図である。コア１は、ステップＳ７００で異常が発生し、機能不全となっているものとする。チェッカ２は、ステップＳ７０１でチェックのためのポーリングをチェッカ１に対して発行し、ステップＳ７０２で無応答カウンタをアップカウント（他の実施形態ではダウンカウントでも構わない）して、無応答期間の計時を開始する。

この時、コア１は機能不全で応答することができないので、チェッカ２は、ステップＳ７０３で無応答回数をチェックし、この実施形態では、まだ無応答回数が設定した回数に達していないので、ステップＳ７０４で一定期間待機する。これを所定期間反復する。

その後、ステップＳ７０５で再度ポーリングを行ない、ステップＳ７０５で無応答カウンタをアップカウントする。ところが、コア１は異常を生じているので無応答となるためステップＳ７０６の無応答回数チェック処理で、無応答回数が規定回数に達したものと判断される。

ステップＳ７０７で、コア２は終了処理を開始し、終了処理が完了した後、ステップＳ７０８で再起動処理を開始させ、コア１、コア２をブートストラップ処理を経由して再起動させ、ＣＰＵ１０１の動作を正常化させる。

＜第２の実施形態＞
以下、本実施形態の第２の実施形態について説明する。第１の実施形態は、ＣＰＵコアの致命的なエラーが発生し、エラーが発生したＣＰＵコアが以後の処理をできない場合を解決する態様について説明した。以下説明する第２の実施形態は、ＣＰＵコアが健全な状態において、コア上で動作しているアプリケーションに何らかのエラーまたは不具合が発生した場合に、将来的なＣＰＵエラーまたはシステムの異常動作を回避するために、ＣＰＵ１０１をリセットすることで、エラー状態から復旧する態様である。

図８は、第２の実施形態におけるＣＰＵ１０１に実装されるソフトウェアの機能ブロック８００を示す。図８に示す機能ブロックは、ＣＰＵ１０１がソフトウェアを実行させることにより、ＣＰＵ１０１上に機能手段として実現される。なお、図８に示す実施形態では、コア２０１は、ＯＳ１としてＲＴＯＳを動作させており、コア２０２は、ＯＳ２としてＬＩＮＵＸ（登録商標）やＵＮＩＸ（登録商標）を動作させているものとして説明するが、コア２０１は、ＬＩＮＵＸ（登録商標）やＵＮＩＸ（登録商標）といったＯＳを動作させることができることは言うまでもないことである。

コア２０１は、ＯＳ１、チェッカ１、およびアプリケーション・マネージャ１を搭載する。ＯＳ１は、第１の実施形態と同様に、コア２０１の動作を制御し、チェッカ１は、コア２０２のチェックを行う。また。第２の実施形態では、他のコア（当該実施例ではコア２０２）に対して再起動を要求する再起動要求手段としても機能する。アプリケーション・マネージャ１は、コア２０１上で動作する各種のアプリケーションＡｐｐ１〜Ａｐｐ４，．．．を登録し、即時終了可能性および即時終了が適切でない場合に実行する終了処理のためのシーケンスを登録する実行リストを管理する。

各アプリケーションＡｐｐ１〜Ａｐｐ４，．．．は、その実行状態に対応した通知を、例えば各種内容を有する通知を、ＯＳの属性に応じて、ＯＳまたはアプリケーション・マネージャに発行する。例えば、ＲＴＯＳとして実装されるＯＳ１で動作するアプリケーション・マネージャ１は、アプリケーションＡｐｐ１〜Ａｐｐ４からアプリケーションの不具合の通知を受領する。その後、アプリケーション・マネージャ１は、コア２のチェッカ２に、コア１がリセット予定であることを通知する。

コア２０２も、コア２０１と同様に複数のソフトウェアを実行させており、ＯＳ２は、コア２０２の動作を制御し、チェッカ２は、コア２０１のチェックを行うと共に、第２の実施形態では、他のコア（当該実施例ではコア２０１）に対して再起動を要求する再起動要求手段としても機能する。説明する実施の形態では、ＯＳ２は、コア２０２上で動作する各種のアプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．の管理を実行しており、アプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．から実行状態に関する通知を受領する。

ＯＳ２は、各アプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．のいずれかが不具合となった通知をアプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．から受領すると、アプリケーション・チェッカ２にアプリケーション識別値を送付し、アプリケーション・チェッカ２を介してコア１のチェッカ１にコア２のリセット予定を通知する。なお、本実施形態におけるアプリケーションは、不正処理が発生したことをＯＳまたはアプリケーション・マネージャに通知する通知手段に相当する。

アプリケーションは、例えばパイプライン処理などを使用して複数が並列実行されており、いずれかのアプリケーションにおいて異常が発生すると、それ以後の処理を実行させることは意味なく、またＣＰＵ１０１が使用されている組み込みシステムの動作に重大な影響を与えることになりかねない。このため第２の実施形態では、各アプリケーションＡｐｐ１〜Ａｐｐ４、Ａｐｐ１０〜Ａｐｐ１３，．．．の実行状態を管理し、アプリケーションの実行に失敗したことをそのステータス情報から検知すると、アプリケーション・マネージャ１およびアプリケーション・マネージャ２を介して他のコアにリセット予定を通知する。この処理を適用することで、正常動作している側のコアの動作に対する影響を最小としながらＣＰＵ１０１をリセットさせ、ＣＰＵ１０１全体を正常な状態に復帰させることができる。

すなわち、図８に示すＣＰＵ１０１は、複数のコア２０１、２０２を動作させているため、例えばコア２０１で動作しているＡｐｐ１に不具合が発生した場合、直ちにＣＰＵ１０１を突然リセットすると、コア２０２が実行させているジョブがリセットされ、ＣＰＵ１０１により制御される各種機器の制御も機器の状態に関わりなく終了されてしまう。この場合、機器は、予測不能な動作を行うことになるので、コア２０１においてアプリケーションの不具合が発生したからと言って、ＣＰＵ１０１全体を直ちにリセットすることはできない。

このため、第２の実施形態では、例えばコア２０１においてアプリケーションの不具合が発生した場合に、コア２０１のアプリケーション・マネージャ１が、コア２０２のチェッカ２にコア２０１がリセット予定であることを通知するリセット予定を発行する。コア２０２のチェッカ２は、リセット予定を受領すると、自己の管理するアプリケーションに対し、適切なシーケンスでアプリケーションを終了させ、実行状態データをメモリに退避させるなどのコア・ダンプ処理を含む終了処理を実行し、リセット準備が完了したことを、コア２０１のチェッカ１に通知し、チェッカ１によるリセット処理を開始させる。

同様に、コア２０２のアプリケーション・マネージャ２も同様の処理を実行し、コア２０２が実行するアプリケーションの不具合が発生した場合、コア２０１に通知し、コア２０２によるリセット許可を待機する。なお、この待機期間中に、コア２０２は、実行時データおよび実行ステータスの退避などの処理を実行することができる。以上のように、第２の実施形態では、コア２０１、２０２自体の動作には支障を来していないので、アプリケーション・マネージャ１またはアプリケーション・マネージャ２からの通知をチェッカ１またはチェッカ２が受領し、リセット処理を開始させる。

このため、第２の実施形態では、将来的に発生する可能性の有るコアのストールに直結するエラーの発生を未然に防止し、効率的、かつ機器に対する影響を最小にしながらシステムをリセットすることを可能とする。

すなわち、第２の実施形態のチェッカ１およびチェッカ２は、それぞれ他のＣＰＵコアの状態をチェックする機能の他、自己のＣＰＵコアにおけるアプリケーション・プログラムの状態をチェックして、他のＣＰＵコアのチェッカに対し、再起動を通知する機能を具備する。なお、アプリケーション・プログラムの不具合としては、例えばスケジューリング違反、記憶保護違反、排他制御違反その他を挙げることができるがこれらに限定されるものではない。

図９は、コア２０１のアプリケーション・マネージャ１が実装するアプリケーションの実行リスト９００を示す。実行リスト９００およびアプリケーション・マネージャ１が、本実施形態における解除手段に相当する。なお、図９に示す実行リスト９００には、アプリケーションが実行開始されると追加され、終了すると、削除される構成とされる。

実行リストには、各アプリケーションＡｐｐ１〜Ａｐｐ４について強制終了する際の終了シーケンスを指定するオブジェクトのリストが対応付けられている。例えばＡｐｐ１を強制的に終了させる場合、Ａｐｐ１は、他のアプリケーションや外部装置に影響を与えることなく終了できる属性を有しているので、オブジェクトｋｉｌｌ１が呼び出され、直ちに終了処理が実行される。

一方、Ａｐｐ２は、他のプロセスに関連するか、または外部装置を駆動するアプリケーションを制御しており、Ａｐｐ２を適切に停止させるためには、関連するプロセスを終了させ、また外部機器の状態も管理および制御する必要がある。このため、アプリケーションＡｐｐ２に対応付けられた終了シーケンスは、各種処理を段階的に終了させ、その後にＡｐｐ２の終了を最後に指示するコマンドを含むｓｈｕｔｄｏｗｎ２オブジェクトが登録されている。

具体的に説明すると、ＯＳ１からアプリケーション・マネージャ１がＡｐｐ２について不正処理が発生したとの通知を受領したものとする。このとき、Ａｐｐ２を即時終了させると、例えば外部機器が動作している場合には、制御不能となる可能性が生じる。アプリケーションＡｐｐ２の異常が通知されると、アプリケーション・マネージャ１は、直ちに終了シーケンスを記述したオブジェクトｓｈｕｔｗｏｄｎ２を呼び出して、外部機器または他のプロセスを正常に停止させる処理を実行させる。

ｓｈｕｔｗｏｄｎ２オブジェクトは、シーケンスに従ってプロセスを終了させ、最後の段階で、Ａｐｐ２を終了させるため例えばｋｉｌｌシグナルを発生させる処理を実行する。この処理が全プロセス（アプリケーション）を終了するまで繰り返される。このため、コア２０１で動作している全プロセス、ひいては外部装置は、不都合を生じることなく、ＣＰＵ１０１のリセット以前に終了される。

図１０は、コア２０２が実装する実行リスト１０００の実施形態を示す。この実施形態では、実行リスト１０００およびアプリケーション・マネージャ１が、本実施形態における解除手段に相当する。コア２０２では、Ａｐｐ１０〜Ａｐｐ１３が実行中であるものとして説明する。この実施形態では、Ａｐｐ１２、Ａｐｐ１３は、即時終了が許可されるプロセスであり、不正発生がチェッカ２から通知されると、ｋｉｌｌ１２、ｋｉｌｌ１３がそれぞれ呼び出され、即時終了処理を実行させる。

一方、Ａｐｐ１０、Ａｐｐ１１は、他のプロセスに対してデータを提供するか、または外部装置を制御するプロセスであるかといった理由から、適切に終了させるためには、オブジェクトに従ったシーケンスで終了させる必要がある。このため、Ａｐｐ１０、Ａｐｐ１１において、不正処理が発生した場合、ｓｈｕｔｄｏｗｎ１０、ｓｈｕｔｏｄｏｗｎ１１オブジェクトが呼び出され、終了シーケンスが開始される。終了シーケンスの内容は、アプリケーションに依存するものの、図９で説明した処理と同様に構成することができる。

なお、図９、図１０では、説明の便宜上、実行リスト９００、１０００を実装するものとして説明したが、他の形式で実装することができるし、各アプリケーションを、あらかじめその終了シーケンスを含ませるように実装させることもできる。当該実施形態の場合には、アプリケーション・マネージャ１またはアプリケーション・マネージャ２が、不正処理を実行したアプリケーションやプロセスに終了を通知する不正終了通知を、例えばシグナルとして送付する構成とすることができる。

本実施形態において終了シーケンスを記述する言語は、特に限定されるものではないが、システムの基幹的な処理を制御するという観点からは、例えばＣ言語やシェルスクリプトまたはこれらを組み合わせたコードで記述することもできる。

また、他の実施形態では、実行リスト９００、または実行リスト１０００に登録されるアプリケーションの実行許可時間を設定しておき、設定した時間を超えて削除されない場合、当該アプリケーションに不具合が発生したものとして、当該アプリケーションの終了シーケンスを開始させることもできる。

図１１は、第２の実施形態におけるＣＰＵ１０１の再起動方法のフローチャートを示す。図１０の処理は、ステップＳ１１００から開始し、Ｓ１１０１〜Ｓ１１０６およびＳ１１０１ａ〜Ｓ１１０６のコア数に対応した並列のステップを含んで実行される。

第２の実施形態では、ステップＳ１１０６のリセット処理は、ステップＳ１１０５またはステップＳ１１０５ａで、（１）少なくとも１のコアがエラーまたはストールが発生したと、健全なコアの側が判定した段階、（２）いずれかのアプリケーション・マネージャがアプリケーション・レベルでの不具合が発生し、健全の方のＣＰＵコアがリセット準備完了した段階で実行される。上述したように、図１０の処理は、ステップＳ１１０５、Ｓ１１０５ａの処理を除き、図４の処理と同様なので、これ以上の詳細な説明は省略する。

図１２は、本実施形態のリセット処理のシーケンス図である。図１２では、アプリケーションの不具合が発生したのがＯＳ２を動作させているコア２０２であるものとして説明する。説明する実施形態では、ＯＳ２は、ＵＮＩＸ（登録商標）またはそれに互換性を有するＯＳが動作しているものとして説明する。

ステップＳ１２００で、ＯＳ２が、アプリケーション・プログラムの実行状態を監視し、例えばアプリケーション・プログラムからの通知を、例えばシグナルとして受信する。ＯＳ２は、当該通知を検査し、当該通知がアプリケーションの正常な実行を阻害するものと判断すると、ＯＳ２上で動作するアプリケーションであるＡｐｐ＃（＃は、１以上の整数である。）に不正処理などの不具合が発生したものと判断する。

ステップＳ１２０１では、ＯＳ２は、ＯＳ２のアプリケーション・マネージャ２に対して検出したアプリケーションにおいて異常終了が発生したことを通知する。アプリケーション・マネージャ２は、当該通知を受領するとステップＳ１２０２でチェッカ２に対してシステム再起動要求を発行する。アプリケーション・マネージャ２は、ステップＳ１２０４で例えば対応するアプリケーションに割り当てられた終了シーケンスを実行するオブジェクトを呼び出し、ＯＳ２の管理下で実行されているアプリケーションの再起動を阻害する要因を解除する処理を実行する。

例えば、当該要因としては、外部機器を制御しているアプリケーションがある場合、アプリケーションの強制終了および強制終了に対応する外部機器の終了処理を行うためのアプリケーションの起動およびその終了の確認などの処理を挙げることができる。また、実行している処理が、時系列的に再実行できる種類のものである場合、実行時ステータスや実行時データのメモリへの退避などを含む。

一方、チェッカ２は、アプリーション・マネージャ２が、再起動阻害要因解除処理を開始すると、ステップＳ１２０３でコア１のチェッカ１に対してシステムが再起動予定であることの通知を、システム再起動要求として発行する。ＯＳ１のチェッカ１は、当該通知を受領すると、ステップＳ１２０５でアプリケーション・マネージャ１に対して再起動可能確認通知を発行する。再起動確認通知を受領したチェッカ１は、アプリケーション・マネージャ１に対して再起動可能確認通知を発行し、アプリケーション・マネージャ１による実行リストの確認を実行させる。その後、コア１は、ステップＳ１２０６で実行中のアプリケーションに対応する終了シーケンスを実行させることで、再起動阻害要因の解除を実行させる。

アプリケーション・マネージャ２は、例えば自己の管理する実行リスト９００のエントリが空になったことを確認すると、ステップＳ１２０７でシステク再起動許可をチェッカ１に対して発行する。チェッカ１は、ステップＳ１２０９でコア・ダンプといったコア２０１の正常終了のための処理を実行した後、ステップＳ１２０９で不正処理が発生した側のコア２０２に対し、システム再起動を許可するシステム再起動指令を発行する。

コア２０２のチェッカ２は、当該通知を受領すると、ステップＳ１２１０でシステム再起動処理を開始する。この時点では、外部装置、コア２０１は正常終了しているので、コア２０２は、コア２０２の権限で例えばＣＰＵ１０１に対し、Ｂｏｏｔｓｔｒａｐ処理を開始させ、ＣＰＵ１０１の再起動を実行し、不正処理による障害を自動的に解消することが可能となる。

図１２に示した実施形態は、例えばＵＮＩＸ（登録商標）、ＬＩＮＩＸ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）といったフルサイズＯＳを実行するコア２０２が実行するアプリケーションで不正処理が発生した場合の実施形態である。

図１３は、例えばＰＯＳＩＸ（登録商標）といったＲＴＯＳを実装するコア２０１において実行されているアプリケーションに不正処理が発生した場合の処理シーケンスを示す。ＲＴＯＳは、ＵＮＩＸ（登録商標）といったフルサイズＯＳに比してライブラリ構成その他に一定の制限があり、またリアルタイム処理が要求されるので図１２の処理に比較して、より即時性の高い不正対応処理を実行する。

図１３の処理は、ステップＳ１３００で、ＯＳ１で実行されているアプリケーションが回復不可能な異常を検出したものとする。回復不能な異常とは、致命的な例外違反である、アンダーフロー、オーバーフローなどを除く、アプリケーション・レベルでの例えば、メモリアクセス不能、特権プロセスの呼び出し失敗、不正データ受領、または待機タイマ満了といった異常を挙げることができるが、これらに限定されるものではない。

異常を検出したアプリケーションは、ステップＳ１３０１でアプリケーション・マネージャ１に対してシステム再起動要求を発行する。アプリケーション・マネージャ１は、当該要求を受領すると、ステップＳ１３０２で再起動阻害要因を解除するべく、実行リスト９００に指定された終了シーケンスを実行するためのオブジェクトを呼び出し、終了シーケンスを実行させる。全プロセスの終了後、アプリケーション・マネージャ１は、ステップＳ１３０４でチェッカ１に対してシステム再起動要求を発行する。

システム再起動要求を受領したチェッカ１は、ステップＳ１３０５でコア２０２のチェッカ２に対してシステム再起動要求を発行し、その後、直ちにステップＳ１３０６でコア２０１の終了処理を実行する。一方、システム再起動要求を受領したチェッカ２は、ステップＳ１３０７でアプリケーション・マネージャ２に対してシステム再起動予告通知を発行する。当該通知を受領したアプリケーション・マネージャ２は、ステップＳ１３０８で実行リスト１０００に登録されているアプリケーションの終了オブジェクトを呼び出し、終了シーケンスを全アプリケーションに対して実行させる。

その終了後、ステップＳ１３０９でチェッカ２に対してシステム再起動式を発行する。チェッカ２は、当該指示を受領すると、ステップＳ１３０１で、コア・ダンプなどの処理を実行し、ステップＳ１３１１で、例えばコア２０２の権限でＢｏｏｔｓｔｒａｐ処理を開始させることで、ＣＰＵ１０１の再起動を実行し、不正処理による障害を自動的に解消することが可能となる。

図１２および図１３において説明したように、再起動（リブート）処理は、フルサイズＯＳを搭載したコアが実行するので、例えば再起動時にもＲＴＯＳの設定を適切に再開させることが可能となる。なお、コア２０１、コア２０２ともにフルサイズＯＳを実装することも可能であるが、この場合、アプリケーションが不正処理を実行した側ではないコアが最終的なリブート処理を実行する態様を採用することにより、より確実な終了およびリブート処理が可能となる。

図１４は、本実施形態においてＣＰＵが２コアではなく、４コアのＣＰＵ１４００の実施形態を示す。４コアの場合には、各コアは、コア間通信部１４０５を通じて通信を実行することができる。そして、４コアの場合には、例えばコア１が能動的監視手段として機能し、コア２〜コア４は、受動的監視手段として機能する。この際、コア１は、コア２〜コア４に対して同報通信またはマルチキャストによりポーリングを行う。

そして、コア１は、当該ポーリングに対するコア２〜４の応答をチェックし、コアごとに、図４のステップＳ１４０４のエラー検出処理を行う。この結果、コア１は、コア２〜コア４のいずれか１からの応答がない場合、当該コアがエラーまたはストールしているものとして再起動処理を行う。

一方、コア２〜コア４の受動的監視手段は、それぞれ図６の処理を行うことで、コア１のエラーまたはストールを判断する。この時、コア２〜コア４のそれぞれの結果をＯＲ処理して、少なくとも１のコアがコア１の異常を検出した場合に、再起動処理を行うことができる。その他、コア２〜コア４の検出結果をＡＮＤ処理し、コア２〜コア４が全部異常判定を行った後に再起動処理を行うこともできる。いずれの処理を採用するかについては、ＣＰＵ１４００の再起動の安定性やＣＰＵ異常が許容される時間ななどに応じて適宜選択することができる。

また、各コア１〜４は、それぞれアプリケーション・マネージャ１〜４を実装し、アプリケーション・レベルでの不正処理に対しても適切に対応することが可能とされている。

＜第３の実施形態＞
以下、本実施形態の第３の実施形態について説明する。第２の実施形態では、図１２において説明したように、ＵＮＩＸ（登録商標）等の異常検出機構を有するフルサイズＯＳが、アプリケーション・プログラムに不正処理などの不具合が発生したかどうかを判断し、不具合が発生したと判断した場合に再起動を行う。すなわち、アプリケーション・プログラムが異常終了する場合、ＯＳが異常の種類別にアプリケーション・プログラムから通知を受け、その通知を基に不具合が発生したと判断する。

しかしながら、アプリケーション・プログラムが異常終了しなくても、回復不可能な問題となり、システム再起動が必要となる場合がある。例えば、本体部と操作部とを備えるＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）等の機器の本体部において、操作部との通信が途絶してしまう場合が挙げられる。すなわち、本体部のアプリケーション・プログラムを異常終了させる必要まではないが、操作部との通信を回復させるために、再起動が必要になる場合である。なお、ここで挙げた例は一例であり、この例に限定されるものではない。

上述したことに鑑み、以下に説明する第３の実施形態は、アプリケーション・プログラムが異常終了せずとも、回復不可能な不正処理などの異常が検出された場合に、ＣＰＵ１０１をリセットすることで、エラー状態から復旧する態様である。

第３の実施形態におけるＣＰＵ１０１に実装されるソフトウェアの機能ブロックは、図８に示した第２の実施形態における機能ブロック８００と同様であるため、図８を参照して説明するが、技術的に重複する内容についてはその説明を省略する。ここでも、コア２０１が、ＯＳ１としてＲＴＯＳを動作させ、コア２０２が、ＯＳ２としてＬＩＮＵＸ（登録商標）等を動作させているものとする。ＯＳ２は、上述した異常検出機構を有するフルサイズＯＳである。

コア２０１上で動作する各アプリケーションＡｐｐ１〜Ａｐｐ４，．．．は、その実行状態に対応した通知をＯＳ１またはアプリケーション・マネージャ１に発行し、回復不可能な異常を検出した場合、アプリケーション・マネージャ１に対してシステム再起動要求を発行する。この処理およびその後の処理は、図１３において既に説明したので、ここではその説明を省略する。

一方、コア２０２上で動作する各アプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．は、自身で回復不可能な異常を検出した場合、ＯＳ２に通知し、ＯＳ２に異常を検出されるのではなく、アプリケーション・マネージャ２に対して自発的にシステム再起動要求を発行する。この点が、図１２において説明した処理内容と異なる点である。このため、各アプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．は、第３の実施形態では他のコア（当該実施例ではコア２０１）に対して再起動を要求する再起動要求手段として機能する。

その後の処理は、第２の実施形態において図１２に示した処理と同様である。このような処理により、アプリケーション・プログラムが異常終了せずとも、回復不可能な異常が検出された場合に、正常動作している側のコアの動作に対する影響を最小としながら、ＣＰＵ１０１をリセットさせ、ＣＰＵ１０１全体を正常な状態に復帰させることができる。

第３の実施形態は、第２の実施形態と同様の機能構成で、コア２０２上で動作する各アプリケーションＡｐｐ１０〜Ａｐｐ１３，．．．が、自発的にシステム再起動要求を発行する以外、図１２において説明した処理と同様であるため、 図９および図１０において説明した実行リストは、第３の実施形態でも使用することができ、その使用態様や使用方法は、第２の実施形態と同様である。また、ＣＰＵ１０１の再起動方法についても、アプリケーション・レベルでの不具合が発生し、健全の方のＣＰＵコアがリセット準備完了した段階で実行されるので、図１１において説明した再起動方法と同様の流れとなる。

第３の実施形態におけるリセット処理について、図１５に示すシーケンス図を参照して詳細に説明する。図１５では、アプリケーションの不具合が発生したのがＯＳ２を動作させているコア２０２であり、ＯＳ２が、ＵＮＩＸ（登録商標）またはそれに互換性を有するＯＳとして説明する。

ステップＳ１５００で、ＯＳ２上で動作するアプリケーションＡｐｐ＃（＃は、１以上の整数である。）に回復不可能な異常が発生し、その異常を検出する。異常は、上述した通信の途絶等である。ステップＳ１５０１では、その異常を検出したアプリケーションＡｐｐ＃が、ＯＳ２とともにコア２０２に実装されるアプリケーション・マネージャ２に対してシステム再起動要求を発行する。アプリケーションＡｐｐ＃がアプリケーション・マネージャ２に対して自発的にその要求を発行するので、第２の実施形態のような実行状態に対応した通知は、ＯＳ２へは発行されない。

その後の処理は、図１２において説明したものと同様であるが、簡単に説明しておく。ステップＳ１５０２では、アプリケーション・マネージャ２が、その要求を受けて、チェッカ２に対してシステム再起動要求を発行する。ステップＳ１５０３では、チェッカ２が、その要求を受けて、他のコアであるコア２０１のチェッカ１に対してシステム再起動要求を発行する。ステップＳ１５０４では、アプリケーション・マネージャ２が、ＯＳ２の管理下で実行されているアプリケーションの再起動を阻害する要因を解除する処理を実行する。

ステップＳ１５０５では、チェッカ１が、チェッカ１からの要求を受けて、コア１に実装されるアプリケーション・マネージャ１に対して再起動可能確認通知を発行する。アプリケーション・マネージャ１は、その通知を受けて、ステップＳ１５０６で再起動を阻害する要因を解除する処理を実行させる。アプリケーション・マネージャ１は、その処理が終了すると、ステップＳ１５０７で、チェッカ１に対してシステム再起動許可通知を発行する。チェッカ１は、ステップＳ１５０８で終了処理を実行し、ステップＳ１５０９で異常を検出したコア２０２に対し、システム再起動を許可するシステム再起動指令を発行する。

異常を検出したコア２０２のチェッカ２は、チェッカ１からの指令を受けて、ステップＳ１５１０でシステム再起動処理を開始する。この場合も、この時点では、外部装置、コア２０１は正常終了しているので、コア２０２は、コア２０２の権限でＣＰＵ１０１に対し、ＢｏｏｔＳｔｒａｐ処理を開始させ、ＣＰＵ１０１の再起動を実行することができ、これにより、アプリケーション・プログラムＡｐｐ＃に発生した異常を自動的に解消することができる。

また、本発明を、１つのＣＰＵ１０１が複数のコアを実装する態様を使用して説明してきたが、他の実施形態では、複数のＣＰＵが独立したコアを構成し、かつ同期的に再起動されるべき構成の複数のＣＰＵを含む、例えばＣＰＵと、ＣＰＵに連携して処理を実行するＧＰＵなど、複数のＧＰＵからなるシステムに対しても適用することができる

これまで本発明を、実施形態をもって説明してきたが、本発明は、実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００ ：電子装置
１０１ ：ＣＰＵ
１０２ ：ＲＡＭ
１０３ ：ＲＯＭ
１０４ ：ＮＶＲＡＭ
１０５ ：通信装置
１０６ ：システムバス
１０８ ：エラー検知部
１０９ ：表示装置
１１０ ：記憶装置
１１１ ：入力装置
１１２ ：電源
１１３ ：ネットワーク
１２０ ：画像形成装置
２０１ ：コア
２０２ ：コア
２０３ ：内部バス
２０４ ：ＩＲＱＨ１（割り込みハンドラ）
２０５ ：通信部
２０６ ：ＩＲＱＨ２（割り込みハンドラ）
２０７ ：割り込みライン
２０８ ：割り込みライン
２０９ ：割り込み入力

特開２０１３−１４９１２８号公報

Claims (14)

1. 複数のコアを有するＣＰＵを備える電子装置であって、
   前記複数のコアのうち第１のコア内に設けられ、前記複数のコアのうちの前記第１のコア以外の第２のコアの異常を能動的に監視する能動的監視手段と、
   前記複数のコアのうち第２のコア内に設けられ、前記第１のコアの異常を前記コアの異常を受動的に監視する受動的監視手段と、
   前記能動的監視手段または前記受動的監視手段のいずれか１つが前記コアの異常を検出することに応答して前記ＣＰＵを再起動させる手段と
   を備える電子装置。
2. 前記能動的監視手段は、前記ＣＰＵの前記複数のコアから１つ決定され、残りのコアが前記受動的監視手段とされる、請求項１に記載の電子装置。
3. 前記能動的監視手段は、前記受動的監視手段からの応答が第１所定期間ないことに基づいて前記コアの異常を検出する、請求項１または２に記載の電子装置。
4. 前記受動的監視手段は、前記能動的監視手段からの問い合わせが第２所定期間ないことに基づいて前記コアの異常を検出する、請求項１〜３のいずれか１項に記載の電子装置。
5. 前記能動的監視手段および前記受動的監視手段の相互監視を行うためのコア間通信手段を含む、請求項１〜４のいずれか１項に記載の電子装置。
6. 前記複数のコアは、少なくとも１つのアプリケーション・プログラムを実行し、
   さらに、
   前記複数のコアは、当該コアで実行される前記アプリケーション・プログラムの不正処理を通知する通知手段と、
   前記不正処理が発生したコアが実行する前記アプリケーション・プログラムの終了を阻害する要因を解除する解除手段と、
   前記アプリケーション・プログラムの不正処理が発生した前記コアを除く他のコアに再起動要求を発行する再起動要求手段とを含む、請求項１〜５のいずれか１項に記載の電子装置。
7. 前記複数のコアは、少なくとも１つのアプリケーション・プログラムを実行し、
   さらに、前記複数のコアが、
   前記アプリケーション・プログラムにより不正処理が検出されたことを受けて、当該アプリケーション・プログラムの不正処理が発生した前記コアを除く他のコアに再起動要求を発行する再起動要求手段と、
   前記不正処理が発生したコアが実行する前記アプリケーション・プログラムの終了を阻害する要因を解除する解除手段とを含む、請求項１〜５のいずれか１項に記載の電子装置。
8. 複数のコアを有するＣＰＵの再起動方法であって、前記ＣＰＵが、
   前記複数のコアのうち第１のコア内に設けられ、前記複数のコアのうちの前記第１のコア以外の第２のコアの異常を能動的に監視するステップと、
   前記複数のコアのうち第２のコア内に設けられ、前記第１のコアの異常を前記コアの異常を受動的に監視するステップと、
   前記能動的に監視するステップまたは前記受動的に監視するステップのいずれか１つが前記コアの異常を検出することに応答して前記ＣＰＵを再起動させるステップと
   を含む再起動方法。
9. 前記受動的に監視するステップからの応答が第１所定期間ないことに基づいて前記コアの異常を検出するステップを含む、請求項８に記載の再起動方法。
10. 前記能動的に監視するステップからの問い合わせが第２所定期間ないことに基づいて前記コアの異常を検出するステップを含む、請求項８または９に記載の再起動方法。
11. 前記複数のコアは、少なくとも１つのアプリケーション・プログラムを実行し、
    さらに、
    当該コアで実行される前記アプリケーション・プログラムの不正処理を通知するステップと、
    前記不正処理が発生したコアが実行する前記アプリケーション・プログラムの終了を阻害する要因を解除するステップと、
    前記アプリケーション・プログラムの不正処理が発生した前記コアを除く他のコアに再起動要求を発行するステップと
    を含む、請求項７〜９のいずれか１項に記載の再起動方法。
12. 複数のコアを有するＣＰＵを再起動するためのＣＰＵ実行可能なプログラムであって、前記ＣＰＵを、
    前記複数のコアのうち第１のコア内に設けられ、前記複数のコアのうちの前記第１のコア以外の第２のコアの異常を能動的に監視する能動的監視手段、
    前記複数のコアのうち第２のコア内に設けられ、前記第１のコアの異常を前記コアの異常を受動的に監視する受動的監視手段、
    前記能動的監視手段または前記受動的監視手段のいずれか１つが前記コアの異常を検出することに応答して前記ＣＰＵを再起動させる手段
    として機能させるためのプログラム。
13. 前記複数のコアは、少なくとも１つのアプリケーション・プログラムを実行し、
    さらに、
    当該コアで実行される前記アプリケーション・プログラムの不正処理を通知する通知手段、
    前記不正処理が発生したコアが実行する前記アプリケーション・プログラムの終了を阻害する要因を解除する解除手段、
    前記アプリケーション・プログラムの不正処理が発生した前記コアを除く他のコアに再起動要求を発行する再起動要求手段
    として機能させる、請求項１２に記載のプログラム。
14. 前記複数のコアは、少なくとも１つのアプリケーション・プログラムを実行し、
    さらに、
    前記コアで実行される前記アプリケーション・プログラムにより不正処理が検出されたことを受けて、当該アプリケーション・プログラムの不正処理が発生した前記コアを除く他のコアに再起動要求を発行する再起動要求手段、
    前記不正処理が発生したコアが実行する前記アプリケーション・プログラムの終了を阻害する要因を解除する解除手段
    として機能させる、請求項１２に記載のプログラム。