JP2016207122A - 電子機器およびリブートプログラム - Google Patents

Abstract

【課題】障害原因がハードウェアかソフトウェアか判断できない場合でも適切に復旧処理を行うことが出来る電子機器およびリブートプログラムの提供。
【解決手段】電子機器の機能をユーザーに提供するアプリケーション・サブシステムと、電子機器のハードウェアを制御するプラットフォーム・サブシステムとを備え、プラットフォーム・サブシステムは、電子機器の個々のハードウェアを制御するプロセスと、プロセスのプロセスダウンを検知するプロセス監視部と、プロセスダウンが検知されたとき復旧のためにプラットフォーム・サブシステムを再起動するシステム状態管理部と復旧までの再起動の回数をカウントするカウンターとを有し、システム状態管理部は、カウンターによりカウントされた復旧までの再起動の回数に基づいて、プロセスダウンがプロセスに起因するかプロセスが制御する個々のハードウェアに起因するかを判断する。
【選択図】図５

Description

本発明は、障害発生時に復旧のために再起動を行う電子機器およびリブートプログラムに関する。

従来、電子機器においてシステムエラーなどの障害が発生すると、稼働中のプログラム（プロセス）をリブート（再起動）することにより、復旧を図ることが行われてきた。

例えば、特許文献１の技術では、障害発生時に取得された障害解析用の情報が、リブート時にクリアされてしまう問題に対処するために、障害が発生した場合は、リブート前に、障害解析用の情報を別の格納領域に待避させる。

また、例えば、特許文献２の技術は、障害発生時の処理に関する技術ではないが、電子機器をサスペンドするときに、揮発性メモリーで構成された主記憶から不揮発性メモリーで構成された補助記憶へ待避させるデータの量を削減するために、主記憶を複数のブロックに分け、ブロックごとに待避させる必要があるか否かを判断するための属性を持たせ、補助記憶に待避させる必要があるブロックのデータのみを補助記憶に待避させる。

また、例えば、特許文献３の技術では、画像形成装置の機能を実現するために稼働しているユーザーアプリケーションにおける障害発生を監視する監視アプリケーションを設け、監視アプリケーションが、ユーザーアプリケーションにおいて発生した障害の程度により、様々な段階の復旧処理を行う。システムの再起動により復旧する障害であれば、システムの再起動が行われる。

また、例えば、特許文献４の技術では、監視ソフトウェアが、被監視ソフトウェアの稼働状況を監視する。障害が発生した時に再起動を行う回数を指定するカウンターを設け、予め決めた回数をカウンターに設定して再起動する。

特開昭６１−１４１０４７号公報 特開平６−１３１０８２号公報 特開２００６−１５７３８６号公報 特開２００２−１４９４３７号公報

上述したように、従来，電子機器において発生した様々な障害に対処するための方法として、電子機器をリブートする方法が用いられてきた。

しかし、電子機器においては、発生した障害がハードウェアに起因するものであるか、ハードウェアを制御するプログラムに起因するものであるか、障害の原因を切り分けることは困難であった。
また、プログラムに起因する障害の場合はリブートすることにより復旧できる確率が高いのに対して、ハードウェアに起因する障害の場合はリブートしても復旧できる確率は低い。
そのため、障害原因がハードウェアかソフトウェアかの判断が出来ない場合でも、障害から復旧するために、リブートを繰り返してしまうという問題点があった。

以上のような事情に鑑み、本発明の目的は、障害原因がハードウェアかソフトウェアか判断できない場合でも適切に復旧処理を行うことが出来る電子機器およびリブートプログラムを提供することにある。

上記目的を達成するため、本発明の一形態に係る電子機器は、電子機器の機能をユーザーに提供するアプリケーション・サブシステムと、前記電子機器のハードウェアを制御するプラットフォーム・サブシステムとを備え、前記プラットフォーム・サブシステムは、前記電子機器の個々のハードウェアを制御するプロセスと、前記プロセスのプロセスダウンを検知するプロセス監視部と、前記プロセスダウンが検知されたとき復旧のために前記プラットフォーム・サブシステムを再起動するシステム状態管理部と復旧までの前記再起動の回数をカウントするカウンターとを有し、前記システム状態管理部は、前記カウンターによりカウントされた復旧までの前記再起動の回数に基づいて、前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかを判断する。そのため、障害原因がハードウェアかソフトウェアか判断できない場合でも適切に復旧処理を行うことが出来る。

上記目的を達成するため、本発明の一形態に係る電子機器は、前記プロセス毎に、前記プラットフォーム・サブシステムの前記再起動の回数と、前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかの判断基準、および再起動の回数ごとの復旧方法を予め定めた障害対応テーブルをさらに備え、前記システム状態管理部は、前記障害対応テーブルに基づいて、前記プロセスダウンの原因の切り分けおよび復旧方法の選択を行う構成でもよい。

上記目的を達成するため、本発明の一形態に係る電子機器では、前記システム状態管理部は、前記プロセスダウンの原因は前記プロセスが制御する前記個々のハードウェアであると判断したとき、前記プロセスに前記プロセスダウンの原因となったハードウェアの制御を停止させる構成でもよい。

上記目的を達成するため、本発明の一形態に係る電子機器では、前記システム状態管理部は、前記プロセスダウンの原因は前記プロセスが制御する前記個々のハードウェアであると判断したとき、前記プロセスダウンの原因となったハードウェアを利用しない旨を前記アプリケーション・サブシステムおよび前記プロセスに通知する構成でもよい。

上記目的を達成するため、本発明の一形態に係るリブートプログラムは、電子機器の機能をユーザーに提供するアプリケーション・サブシステム、および前記電子機器のハードウェアを制御するプラットフォーム・サブシステムとして動作し、前記プラットフォーム・サブシステムは、前記電子機器の個々のハードウェアを制御するプロセスと、前記プロセスのプロセスダウンを検知するプロセス監視部と、前記プロセスダウンが検知されたとき復旧のために前記プラットフォーム・サブシステムを再起動するシステム状態管理部と復旧までの前記再起動の回数をカウントするカウンターとを有し、前記システム状態管理部は、前記カウンターによりカウントされた復旧までの前記再起動の回数に基づいて、前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかを判断する手順をコンピューターに実行させる。

以上のように、本発明によれば、障害が発生しても全体をリブートすることなく復旧を行うことが出来る。

画像形成装置２０の構成を概略的に示す構成図である。 制御部２１の構成図である。 アプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明するための図である。 プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明するための図である。 障害対応テーブル８の例を示す図である。

以下、図面を参照しながら、本発明の実施形態を説明する。なお、以下の説明では、電子機器の例として画像形成装置（ＭＦＰ、Multifunction Peripheral）を用いて説明する。

［画像形成装置の構成］
最初に、画像形成装置の構成を説明する。図１は画像形成装置２０の構成を概略的に示す構成図である。

画像形成装置２０は、制御部２１を備える。制御部２１は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、および専用のハードウェア回路等から構成され、画像形成装置２０の全体的な動作制御を司る。

制御部２１は、画像読取部２２、画像処理部２３、画像メモリー２４、画像形成部２５、操作部２７、ファクシミリ通信部２８、ネットワークインターフェイス部２９、記憶部３０等と接続されている。制御部２１は、接続されている上記各部の動作制御や、各部との間での信号又はデータの送受信を行う。

制御部２１は、ユーザーから、操作部２７またはネッワーク接続されたＰＣ（Personal Computer）等を通じて入力されるジョブの実行指示に従って、スキャナ機能、印刷機能、コピー機能、およびファクシミリ送受信機能などの各機能についての動作制御を実行するために必要な機構の駆動及び処理を制御する。制御部２１の詳細は後述する。

画像読取部２２は、原稿から画像を読み取る。

画像処理部２３は、画像読取部２２で読み取られた画像の画像データを必要に応じて画像処理する。例えば、画像処理部２３は、画像読取部２２により読み取られた画像が画像形成された後の品質を向上させるために、シェーディング補正等の画像処理を行う。

画像メモリー２４は、画像読取部２２による読み取りで得られた原稿画像のデータを一時的に記憶したり、画像形成部２５での印刷対象となるデータを一時的に記憶したりする領域である。

画像形成部２５は、画像読取部２２で読み取られた画像データ等の画像形成を行う。

操作部２７は、画像形成装置２０が実行可能な各種動作及び処理についてユーザーからの指示を受け付けるタッチパネル部および操作キー部を備える。タッチパネル部は、タッチパネルが設けられたＬＣＤ（Liquid Crystal Display）等の表示部２７ａを備えている。

ファクシミリ通信部２８は、図示しない符号化／復号化部、変復調部、およびＮＣＵ（Network Control Unit）を備え、公衆電話回線網を用いてのファクシミリの送信を行う。

ネットワークインターフェイス部２９は、ＬＡＮ（Local Area Network）ボード等の通信モジュールから構成され、ネットワークインターフェイス部２９に接続されたＬＡＮ等を介して、ローカルエリア内の装置(ＰＣ等)と種々のデータの送受信を行う。

記憶部３１は、画像読取部２２によって読み取られた原稿画像等を記憶する、ＨＤＤ（Hard Disk Drive）などの大容量の記憶装置である。

以上、画像形成装置２０の構成について説明した。

［制御部の構成］
次に、制御部２１の構成について説明する。図２は、制御部２１の構成図である。

制御部２１は、大きくアプリケーション・サブシステム１とプラットフォーム・サブシステム５とに分けて構成される。

アプリケーション・サブシステム１は、画像形成装置２０の機能毎に独立した独立プロセス２ａ、２ｂ、・・・と、プロセス監視部３と、システム状態管理部４と、障害対応テーブル８とから構成される。

独立プロセス２ａ、２ｂ、・・・は、一般的なＰＣにおいて、文書作成ソフトウェアや表計算ソフトウェアのようなアプリケーションプログラムに相当するものである。

プロセス監視部３は、アプリケーション・サブシステム１内で稼働している独立プロセス２ａ、２ｂ、・・・の稼働状態を監視する。例えば、独立プロセス２ｂにおいて障害が発生し、独立プロセス２ｂがダウンすると、プロセス監視部３がプロセスダウンを検知する。

システム状態管理部４は、制御部２１内の各独立プロセスの現在の稼働状況を管理して稼働状況を表示部２７ａに表示したり、アプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・においてプロセスダウンが発生したプロセスをリブートしたりする。

障害対応テーブル８は、システム状態管理部４がプラットフォーム・サブシステム５において発生した障害からの復旧のために、プラットフォーム・サブシステム５をリブートする回数を制御するものである。詳細は後述する。

プラットフォーム・サブシステム５は、制御するハードウェア毎に独立した独立プロセス（プロセス）６ａ、６ｂ、６ｃ、・・・と、プロセス監視部７とから構成される。

独立プロセス６ａ、６ｂ、６ｃ、・・・は、一般的なＰＣにおいて、ＯＳ（Operating System）の各部に相当するものである。

なお、アプリケーション・サブシステム１内の各独立プロセス２ａ、２ｂ、・・・は、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・を利用することにより、ユーザーから指示された機能を実現する。

なお、独立プロセス６ａ、６ｂ、６ｃ、・・・は、それぞれ、リブート回数カウンター９ａ、９ｂ、９ｃ、・・・を備えている。リブート回数カウンター９ａ、９ｂ、９ｃ、・・・は、独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれか、または独立プロセス６ａ、６ｂ、６ｃ、・・・が制御するハードウェアのいずれかにおいて障害が発生し、独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかがダウン（プロセスダウン）したときに、復旧のために、プラットフォーム・サブシステム５のリブートを試みる回数をカウントする。

プロセス監視部７は、プラットフォーム・サブシステム５内で稼働している独立プロセス６ａ、６ｂ、６ｃ、・・・の稼働状態を監視する。

例えば、独立プロセス６ａは、ハードウェアである画像読取部２２の制御を行うものであり、画像読取部２２に障害が発生した場合および独立プロセス６ａ自体に障害が発生した場合、プロセス監視部７は、障害を独立プロセス６ａの障害として検知する。

なお、プロセス監視部３とプロセス監視部７は、互いに、アプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・のプロセスダウンと、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・のプロセスダウンとを通知し合って連携している。

以上、制御部２１の構成について説明した。

［処理の流れ１］
次に、アプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明する。図３は、アプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明するための図である。

（１）まず、アプリケーション・サブシステム１内の独立プロセス２ｂにおいて障害が発生したとする。

（２）次に、プロセス監視部３が独立プロセス２ｂのプロセスダウンを検知する。

（３）次に、プロセス監視部３は、プラットフォーム・サブシステム５のプロセス監視部７に対し、独立プロセス２ｂに障害が発生した旨のシステムエラー発生通知（エラー発生通知）を送る。

（４）プロセス監視部７は、プラットフォーム・サブシステム５内の各独立プロセス６ａ、６ｂ、６ｃ、・・・に対し、独立プロセス２ｂにおいて障害が発生した旨のシステムエラー発生通知を送る。

なお、システムエラー発生通知を受信した独立プロセス６ａ、６ｂ、６ｃ、・・・は、独立プロセス２ｂのリブートが完了するまでの特定期間、独立プロセス２ｂとの通信を控えるので、独立プロセス２ｂとの通信が出来ない事によるエラーの発生を抑えることが出来る。

なお、システムエラー発生通知を受信した独立プロセス６ａ、６ｂ、６ｃ、・・・が独立プロセス２ｂとの通信を控えるのは、特定の時間が経過するまでとする構成以外に、リブートが完了した独立プロセス２ｂからリブートが完了した旨の通知を受けてから独立プロセス２ｂとの通信を再開する構成でもよい。

（５）次に、プロセス監視部３は、システム状態管理部４に対し、独立プロセス２ｂに障害が発生した旨のシステムエラー発生通知を送る。

（６）次に、システム状態管理部４が、受信したシステムエラー発生通知に基づいて独立プロセス２ｂをリブートする。システム状態管理部４は、障害が発生した独立プロセス２ｂと同じアプリケーション・サブシステム１内にあるので、リブート処理を容易に行うことが出来る。

なお、プロセス監視部３からのシステムエラー発生通知は、上記の順序に限らず、プロセス監視部３およびプロセス監視部７に対して同時に行われてもよいし、どちらに対して先に送信してもよい。

以上がアプリケーション・サブシステム１内の独立プロセス２ａ、２ｂ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れである。

なお、本発明では、１つの独立プロセス２ａ、２ｂ、・・・上において発生した障害は、障害が発生した独立プロセス２ａ、２ｂ、・・・をリブートすることにより障害から復旧させることが出来ることを前提としている。

以上のように、本発明に係る画像形成装置２０では、例えば、コピー機能に障害が発生しても、その障害がファクシミリ機能に影響を与えることは無く、また、コピー機能を担当する独立プロセスのみをリブートすることにより障害から復旧させることが出来る。

［処理の流れ２］
次に、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明する。図４は、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れを説明するための図である。

（１）まず、プラットフォーム・サブシステム５内の独立プロセス６ｃにおいて障害が発生したとする。

（２）次に、プロセス監視部７が独立プロセス６ｃのプロセスダウンを検知する。

（３）次に、プロセス監視部７は、アプリケーション・サブシステム１のプロセス監視部３に対し、独立プロセス６ｃに障害が発生した旨のシステムエラー発生通知を送る。

（４）次に、プロセス監視部３は、システム状態管理部４に対し、独立プロセス６ｃに障害が発生した旨のシステムエラー発生通知を送る。

（５）次に、システム状態管理部４は、プラットフォーム・サブシステム５全体をリブートする。なお、システム状態管理部４は、画像形成装置２０全体をリブートする構成でもよい。

なお、独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかにおいて障害が発生した場合は、プラットフォーム・サブシステム５全体の動作が不安定になるため、プラットフォーム・サブシステム５内の個々の独立プロセス６ａ、６ｂ、６ｃ、・・・単独ではなく、プラットフォーム・サブシステム５全体がリブートされる。

以上が、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・のいずれかにおいて障害が発生した場合のリブート処理の流れである。

［リブート回数に基づいた障害原因の切り分けと障害対応］
次に、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・においてプロセスダウンが発生した場合の、リブート回数に基づいた障害原因の切り分けと障害対応について説明する。図５は、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・においてプロセスダウンが発生した場合の、リブート回数に基づいた障害原因の切り分けと障害対応に用いる障害対応テーブル８の例を示す図である。

例えば、独立プロセス６ａは、ハードウェアである画像読取部２２を制御するプロセスであり、独立プロセス６ａまたは画像読取部２２において障害が発生すると、その障害は独立プロセス６ａのプロセスダウンとしてプロセス監視部７に検知される。

独立プロセス６ａのプロセスダウンを検知したプロセス監視部７は、システムエラー発生通知をシステム状態管理部４に通知する。

システム状態管理部４は、障害対応テーブル８とリブート回数カウンター９ａを参照し、独立プロセス６ａがプロセスダウンした時の復旧処理１回目の処理はリブートすることであると判断する。

そして、システム状態管理部４により、１回目のプラットフォーム・サブシステム５のリブートが行われる。また、リブート回数カウンター９ａのカウントアップが行われる。

リブート後、独立プロセス６ａが復旧した場合、発生していた障害は独立プロセス６ａに起因するソフトウェア的な障害であったと判断する。復旧は完了しているので更なる障害対応は行わない。そして、リブート回数カウンター９ａはリセットされる。

リブート後、独立プロセス６ａが復旧していない場合、システム状態管理部４は、再度、障害対応テーブル８とリブート回数カウンター９ａを参照し、２回目の復旧処理としてプラットフォーム・サブシステム５のリブートを行う。

２回目のリブート後も独立プロセス６ａが復旧しない場合、障害対応テーブル８とリブート回数カウンター９ａを参照し、３回目のリブートを行う。

３回目のリブート後も独立プロセス６ａが復旧しない場合、障害対応テーブル８とリブート回数カウンター９ａを参照し、システム状態管理部４は、独立プロセス６ａにおいて発生している障害が、リブートにより復旧される確率の高い独立プロセス６ａ自体の障害ではなく、リブートにより復旧される確率の低い、ハードウェアである画像読取部２２に起因するものであると判断する。

障害がハードウェアによるものであると判断したシステム状態管理部４は、画像読取部２２に対する制御を停止し、画像読取部２２を制御対象から切り離す。

また、システム状態管理部４は、アプリケーション・サブシステム１およびプラットフォーム・サブシステム５内の各独立プロセスに対し、画像読取部２２が使用不能であることを通知する。

通知を受けた各独立プロセスは、画像読取部２２が無いものとして、画像読取部２２と独立している機能のみをユーザーに提供し、画像読取部２２が無いことに起因するエラーは生じさせない。

このように、障害対応テーブル８は、特定のリブート回数までに障害が復旧すれば障害はソフトウェアに起因するものであり、特定の回数だけリブートしても障害から復旧できないときは障害がハードウェアに起因するものであると判断する基準であり、かつリブート回数ごとに選択する復旧方法を予め定めたものとなる。

以上が、図５に例示した障害対応テーブルの設定内容と、その設定内容に基づいて、独立プロセス６ａがプロセスダウンした際に行われる処理である。

なお、ハードウェアの特性およびハードウェアを制御する独立プロセスの特性に応じて、障害原因を切り分けるためにリブートすべき回数は異なる。リブートにより復旧する確率を予め計測しておき、計測結果に基づいて復旧処理の何回目までリブートするかを決めるとよい。

すなわち、例えば、独立プロセス６ａは構造が複雑であるなどの理由によりリブートにより復旧する確率が低いので、３回リブートしてみるまでは、障害の原因がハードウェアであるとは判断できない。

それに対し、記憶部３０を制御する独立プロセス６ｃでは、構造が簡単である等の理由によりリブートにより復旧する確率が高いので、１回リブートしても復旧できない場合は障害の原因がハードウェアであると判断することが出来る。

以上、プラットフォーム・サブシステム５内の独立プロセス６ａ、６ｂ、６ｃ、・・・においてプロセスダウンが発生した場合の、リブート回数に基づいた障害原因の切り分けと障害対応について説明した。

［補足事項］
その他、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

１ … アプリケーション・サブシステム
２ａ、２ｂ… 独立プロセス
３ … プロセス監視部
４ … システム状態管理部
５ … プラットフォーム・サブシステム
６ａ、６ｂ、６ｃ… 独立プロセス
７ … プロセス監視部
８ … 障害対応テーブル
９ａ、９ｂ、９ｃ… リブート回数カウンター
２０ … 画像形成装置
２１ … 制御部
２２ … 画像読取部
２３ … 画像処理部
２４ … 画像メモリー
２５ … 画像形成部
２７ … 操作部
２７ａ… 表示部
２８ … ファクシミリ通信部
２９ … ネットワークインターフェイス部
３０ … 記憶部

Claims (5)

1. 電子機器の機能をユーザーに提供するアプリケーション・サブシステムと、
   前記電子機器のハードウェアを制御するプラットフォーム・サブシステムと
   を備え、
   前記プラットフォーム・サブシステムは、
   前記電子機器の個々のハードウェアを制御するプロセスと、
   前記プロセスのプロセスダウンを検知するプロセス監視部と、
   前記プロセスダウンが検知されたとき復旧のために前記プラットフォーム・サブシステムを再起動するシステム状態管理部と
   復旧までの前記再起動の回数をカウントするカウンターと
   を有し、
   前記システム状態管理部は、
   前記カウンターによりカウントされた復旧までの前記再起動の回数に基づいて、
   前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかを判断する
   電子機器。
2. 請求項１に記載の電子機器であって、
   前記プロセス毎に、前記プラットフォーム・サブシステムの前記再起動の回数と、
   前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかの判断基準、および
   再起動の回数ごとの復旧方法を予め定めた障害対応テーブルをさらに備え、
   前記システム状態管理部は、
   前記障害対応テーブルに基づいて、前記プロセスダウンの原因の切り分けおよび復旧方法の選択を行う
   電子機器。
3. 請求項１または２に記載の電子機器であって、
   前記システム状態管理部は、
   前記プロセスダウンの原因は前記プロセスが制御する前記個々のハードウェアであると判断したとき、
   前記プロセスに前記プロセスダウンの原因となったハードウェアの制御を停止させる
   電子機器。
4. 請求項３に記載の電子機器であって、
   前記システム状態管理部は、
   前記プロセスダウンの原因は前記プロセスが制御する前記個々のハードウェアであると判断したとき、
   前記プロセスダウンの原因となったハードウェアを利用しない旨を前記アプリケーション・サブシステムおよび前記プロセスに通知する
   電子機器。
5. 電子機器の機能をユーザーに提供するアプリケーション・サブシステム、および
   前記電子機器のハードウェアを制御するプラットフォーム・サブシステムとして動作し、
   前記プラットフォーム・サブシステムは、
   前記電子機器の個々のハードウェアを制御するプロセスと、
   前記プロセスのプロセスダウンを検知するプロセス監視部と、
   前記プロセスダウンが検知されたとき復旧のために前記プラットフォーム・サブシステムを再起動するシステム状態管理部と
   復旧までの前記再起動の回数をカウントするカウンターと
   を有し、
   前記システム状態管理部は、
   前記カウンターによりカウントされた復旧までの前記再起動の回数に基づいて、
   前記プロセスダウンが前記プロセスに起因するか前記プロセスが制御する前記個々のハードウェアに起因するかを判断する
   手順をコンピューターに実行させるリブートプログラム。

Images