JP2009505172A - 電子器具および装置の初期化中におけるエラーを検出するための方法 - Google Patents

Abstract

本発明は、電子器具の常駐ソフトウェアの起動段階において起こる問題を検出する方法に関する。本検出は、本段階において、データを非揮発性のメモリに書き込む手段によって実施される。本データは、成功するケースでは消去される。失敗するケースでは、次のリスタートにおいて、本データを問題の検出に用いることが可能である。

Description

本発明は、電子デバイス（electronic device）の初期化の分野、より正確には、デバイス中に組み込まれたオペレーティングシステムの初期化段階において起こる問題の検出（detection）に関する。

オペレーティングシステムを伴う電子デバイスの初期化スキーマは、一般的には、以下の通りである。

第一段階では、システムカーネルは、メモリにロードされ、実行される。このカーネルは、一般的には、最小となるように設計される。カーネルは、メモリマネージャ、タスクスケジューラなどの最小限の基本的な機能を提供する。このカーネルは、通常は、静的に設計されるので、初期化および起動（launch）が再現可能である。したがって、ハードウェアの誤動作がない限り、カーネルの初期化は、当然成功する。

第二段階では、一定数のサービスが起動される。これらのサービスは、システムのより精巧な機能を提供する。これらのサービスは、カーネルによってサポートされる。これらのサービスは、例えば、周辺装置の管理、デバイスの外部通信層の任意の必要な管理、入力／出力周辺装置、ネットワークなどを提供する。これらのサービスはまた、デバイスの特定目的に関する任意のサービスと同様にデバイスの前回の使用において保存された構成パラメータのリカバリーを備えることと同様に、ユーザーの好みの管理を備えることもできる。

これらのサービスの複雑性、および、ユーザーおよびデバイスの環境パラメータの認識は、この段階の成功を保証することをさらに困難にする。実際、全てのシナリオをテストすることはできず、エラーはまだ発生する可能性がある。

第三段階では、一旦、システムを作る全てのサービスが起動されると、アプリケーションも起動される。これは、その環境内でデバイスの機能を完結させるであろうアプリケーションである。このアプリケーションは、完全で操作可能なオペレーティングシステムにおいて起動される。システムは、一般的に、アプリケーション内で起こるエラーを正すことを可能にする。アプリケーションの再起動は、かなり頻繁で、十分である。

我々は、それゆえ、最も重要なエラーは、第二段階、すなわちサービス起動段階において起こるエラーであること理解することができる。これらのエラーの処理を試みるための方法が存在する。例えば、パーソナルコンピュータの世界では、システムは、一般的に、最小システムの起動から成る「エラーフリー（error-free）」モードを含むいくつかの起動モードを提供する。この最小システムは、一般的に、サービスを初期化することを試みず、これらのサービスの起動パラメータを正すため、ユーザーにインターフェースを提供する。この手法においては、初期化エラーに直面すると、ユーザーは、このエラーの原因を正し、使用可能なデバイスにリカバリーすることができる。この修正は、システムの完全な置換にまで及ぶことができる。この方法は、コンピュータの世界では正しく機能するが、そのような問題に関する寛大性（indulgence）と同様に、ユーザーに一定のスキルを要求する。

しかしながら、「汎用（general public）」電子の分野では、同等の方法を適用することは、考慮されない。さらに、汎用デバイス（general public device）のユーザーは、デバイスの誤動作を簡単に受け入れようとはしない。実際、汎用デバイスのユーザーは、複雑性のレベルが低く、一般的に誤動作のないデバイスに順応している。また、そのようなユーザーに、潜在的な問題を「手動で（manually）」正すのに必要なスキルを有することを要求することができない。

エラーを正すことを可能にする第一の対策は、システムを更新する能力である。この可能性は、多くのデバイスに存在する。例えば、パーソナルコンピュータに接続することができるデバイスを、しばしばこのコンピュータからのシステムの改版によって更新することができる。デジタルテレビの受信デバイスもまた、一般的に、システムのソフトウェアの新しいバージョンの受信を通じて更新することができる。この方法は、システムの設計エラーまたはこのシステムのメモリダンプの破損を克服することを可能にし、または新しい機能を追加することを可能にする。ダウンロードオペレーションを開始させる決定は、一般的に、一定数の基準が合致するときにのみ、なされる。これらの基準は、新しい常駐ソフトウェア（resident software）バージョンの存在、またはデバイス内の本ソフトウェアの破損したバージョンの検出である。

米国特許第６，３９３，５８５号明細書は、そのような方法による端末の起動を開示している。この明細書によると、ユーザーは、始動において最初のアプリケーションをロードして起動し、問題が起こると、ユーザーは、別のアプリケーションをロードする。そのような方法は、始動の問題を詳細に取り扱うことを可能にすることはできない。

汎用デバイス内のエラーを取り扱う別の対策は、デバイスをリスタートする追加的可能性である。このリスタートのオペレーションは、自動とすることができるか、またはユーザーによる特定のアクションによって制御することができる。このリスタートの対策は、システムを再起動することを可能にし、デバイスの使用において起こるエラーを処理することを可能にする。

それゆえ、新しいソフトウェアバージョンのダウンロードをトリガするための基準が、合致せず、システムサービスの初期化段階が、問題につながる可能性がある。このケースでは、問題は、システムのリスタートを招く。全てエラーにつながる一連のリスタートが発生し、それゆえ新しいリスタートにつながる。

本発明は、電子デバイスの常駐ソフトウェアの起動段階において起こる問題を検出することを可能にし、起動段階をいくつかのステップまたはモジュールに分割することを可能にする。この検出は、この段階において各モジュールの起動の前に、不揮発性のメモリに書き込まれる情報を用いてなされる。この情報は、成功する場合には削除される。失敗する事象では、次のリスタートにおいて、この情報を用いて、問題および関連するモジュールを検出することができる。ユーザーは、それゆえ、始動において起こりうる問題の検出が高精度（high precision）になることによって利益を得られる。

本発明は、永続メモリを備える電子デバイスの始動において起こるエラーを検出する方法であって、このデバイスは常駐ソフトウェアによって駆動され、少なくとも以下のステップを備える方法に関する。
第一の始動において、情報をデバイスのメモリに書き込む少なくとも１のステップ、
第二の始動において、第一の始動においてメモリに書き込まれたその情報に従って、第一の始動において起こったエラーを検出するステップ。
有利なことに、始動プロセスは、複数モジュールの連続起動を伴い、各モジュールが起動する前に情報をメモリに書き込むステップを備える。

特定の実施形態によると、方法はまた、常駐ソフトウェアの少なくとも一部のエラーフリーの起動が完了するとメモリに書き込まれた情報を削除するステップをも備える。

特定の実施形態によると、エラー検出ステップは、始動プロセスにおいてメモリに書き込まれたその情報の存在を検出することによってなされる。

特定の実施形態によると、方法はまた、エラーを生成した少なくとも１つの前回の始動の検出に続いてアラートのトリガをも備える。

特定の実施形態によると、方法はまた、アラームがトリガされると、デバイスの少なくとも１つのパラメータのデフォルト値を再格納するステップをも備える。

特定の実施形態によると、方法はまた、アラームがトリガされると、次のデバイスの始動において、少なくとも１つのモジュールの起動を非アクティブにするステップをも備える。

特定の実施形態によると、方法はまた、アラームがトリガされると、常駐ソフトウェアの新しいバージョンのダウンロードを引き起こすステップをも備える。

特定の実施形態によると、方法はまた、アラームがトリガされると、ユーザーに対して情報の表示を引き起こすステップをも備える。

本発明はまた、永続メモリと、電子デバイスを制御するように設計された常駐ソフトウェアと、始動プロセスにおいて各モジュールの起動の前に情報をデバイスのメモリに書き込む手段を備えるデバイスの始動における常駐ソフトウェア起動手段であって、その始動プロセスが複数モジュールの連続起動を備える手段と、始動プロセスにおいてメモリに書き込まれたその情報に従って、前回の始動において起こったエラーを検出する手段とを備える電子デバイスに関する。

特定の実施形態によると、デバイスはまた、常駐ソフトウェアの少なくとも一部のエラーフリーの起動が完了するとメモリに書き込まれた情報を削除する手段をも備える。

特定の実施形態によると、デバイスはまた、エラーを生成した少なくとも１つの前回の始動の検出に続くアラームをトリガする手段をも備える。

特定の実施形態によると、デバイスはまた、アラームがトリガされると、デバイスの少なくとも１つのパラメータのデフォルト値をリセットする手段をも備える。

特定の実施形態によると、デバイスはまた、アラームがトリガされると、次のデバイスの始動において、少なくとも１つのモジュールの起動を非アクティブにする手段をも備える。

特定の実施形態によると、デバイスはまた、アラームがトリガされると、常駐ソフトウェアの新しいバージョンのダウンロードを引き起こす手段をも備える。

特定の実施形態によると、デバイスはまた、アラームがトリガされると、ユーザーに対して情報を表示する手段をも備える。

本発明は、添付した図面について触れている次の詳細な説明を読むことにより、より理解することができ、他の特定の機能（feature）および利点が明らかになるであろう。

ここに説明しようとする本発明の実施形態は、デジタルテレビデコーダの分野で見受けられるが、この分野に限定されるものではない。これらのデコーダは、放送（broadcast）されたテレビサービスを受け取り、復号することができる。そのようなサービスを、いくつかの種類の技術、例えば、サテライト、ケーブル、地上波、およびインターネットのような最近のコンピュータネットワークで放送することができる。これらのサービスは、一般的に、いくつかのサービスが結合できる場所、および各サービスの異なるコンポーネントが結合する場所において、デジタルデータのストリームの形式で放送される。これらのコンポーネントは、オーディオコンポーネント、ビデオコンポーネント、および情報をサービス上に含むことができる。電子プログラミングガイドを表示する情報、対話式アプリケーション、および他の種類の情報もまた、ストリーム内で見受けられる。これらのコンポーネントのいくつかは、圧縮することができ、サービスは、一般的に、サービスを見る権限のある人によってのみ用いられるそのような方法でエンコードされる。そのようなサービスを見るには、ブロードキャストデジタルストリームを受け取ることができ、分離し、復号し、復元し、ブロードキャストデジタルストリームをリカバリーする目的で異なるコンポーネントの同期をとることができるデコーダデバイス、例えば、テレビセットの使用が必要である。デコーダはまた、プログラムガイドなどのデータおよび関連プログラム、およびゲームまたはその他のアプリケーションを受け取り、格納し、表示することができなければならない。

そのようなデバイスのアークテクチャの例を、図２に図示する。デコーダ自体は、ボックス２．１の輪郭である。例として与えられるデコーダは、インターネットのようなコンピュータネットワークを介してサービスを受け取るデコーダである。デコーダは、それゆえ、ラベル２．７のイーサーネット（登録商標）インターフェースを介して、モデム、例えば電話線を用いることで接続を提供するラベル２．２のＤＳＬ（Digital Subscriber Line）に接続される。受け取ったデータのストリームは、プロセッサ２．９の制御下でバス２．１を通過した後に、ラベル２．１２のデマルチプレクサによって分離されるであろう。オーディオおよびビデオコンポーネントは、それからラベル２．６のデコーダによって、復号され、および／または復元される。メニューなどの任意の追加的データは、ラベル２．８のグラフィックスプロセッサによって処理されるであろう。デコーダ２．６およびグラフィックスプロセッサ２．８からのデータは、ラベル２．４のデジタル・アナログ変換器によって、オーディオおよびビデオ信号に変換されるであろう。ラベル２．５のこれらの信号は、ＰＡＬまたはＮＴＳＣなどのテレビ規格に従って、ラベル２．３のテレビセットの表示用に作成される。デコーダは、プロセッサ２．９によって制御される。このプロセッサは、ラベル２．１０のフラッシュメモリに格納されたオペレーティングシステムを実行する。このフラッシュメモリは、永続するプロパティを有し、そこに格納された情報は、それゆえ、デバイスの電源装置のスイッチが切られても、メモリ中に保持される。このシステムは、ＲＡＭ（ランダムアクセスメモリ）を作業メモリとして用いる。

このタイプのデバイスは、一般的に、ソフトウェア層の制御下で動作し、このアーキテクチャの例を、図３に示す。この図では、デコーダのハードウェアは、ボックス３．１１で表される。ラベル３．１０の最初のドライバ層は、このハードウェアを管理することを可能にする。ラベル３．２のシステムカーネルは、タスクマネージャおよびスケジューラのような基本的なシステムメカニズムを実装する。デコーダとＩＰネットワーク間の通信は、ラベル３．９のＩＰスタックにより管理される。一定数のモジュールは、システムカーネル上で実装され、いくつかのモジュールは、ＩＰ通信層の上で実装される。これらのモジュールのうちの１つは、限定的な手法で、一組のデコーダを中央コンソールから管理することを可能にするために用いられるラベル３．４のＳＮＭＰ（Simple Network Management Protocol）クライアントを見つけることができる。常駐ソフトウェアの管理を可能にするラベル３．５の更新マネージャも見受けられ、新しいソフトウェアのパーツをダウンロードすることによって、更新することができる。さらに、ユーザーが、実際に、例えばテレビの要求に応えるコンテキスト内で受け取られたストリームを見る権限を与えられていることのチェックに用いられるラベル３．６の条件付きアクセスモジュールが見受けられる。ラベル３．７のビデオオンデマンド（ＶＯＤ）モジュールは、オンデマンド・ブロードキャスト・コンテンツに対するアクセスを制御することを可能にする。ラベル３．８のマルチキャスト・ブロードキャスト制御モジュールは、テレビサービスを含むストリームのこのモード内で受信を管理することができる。ラベル３．３のサービスのリストの制御モジュールは、使用する権利を有するサービスのリストをリカバリーし、維持することができる。

これらのモジュールは、それゆえ、一連のサービスを提供し、一般的に、システムカーネルの機能が、カーネルによって管理されスケジュールされるタスクとして起動されるという意味で、それらのサービスは、システムカーネルの機能を用いる。システムカーネルの機能のニーズによると、システムカーネルの機能はＩＰ通信層またはハードウェアドライバを使用することができる。例えば、アクセス制御モジュールは、チップカード（chip-card）読み取りモジュールドライバを用いるであろう。

全体として、デバイスは、ラベル３．１のアプリケーションによって管理され、その目的は、ユーザーにデバイスのオペレーティングデバイスを提供することである。このアプリケーションは、それゆえ、接続されたテレビセットを介して、利用可能なプログラムのリスト、プログラムの１つを選択する可能性、およびデコーダによるそのプログラムの受信の表示などの一組の機能を提供するであろう。操作するために、それらの機能のそれぞれは、モジュールのサービス、およびデバイス上で起動されたシステムのサービスを用いるであろう。

ドライバ、カーネル、モジュール、およびアプリケーションを備える常駐ソフトウェアのこのセットは、フラッシュメモリに格納される。デバイスが始動すると、ソフトウェアを、一般的に、ＲＡＭにロードしなければならず、図４に図示した順序で起動しなければならない。ラベルＥ１の第一のステップでは、デコーダが始動する。それから、ラベルＥ２の第二のステップでは、常駐ソフトウェア、カーネル、ドライバ、サービスモジュール、およびアプリケーションのイメージの整合性を検証する。実際、フラッシュメモリ、または他の種類の永続メモリに格納されたソフトウェアの破損にとって、システムを含み、このソフトウェアの整合性を検証し、破損の事象内に完全な置換バージョンをダウンロードすることは、従来的なことである。このシステムは、メモリ内に完全なソフトウェアから計算された符号を追加するＣＲＣ（Cyclic Redundancy Code）の原理で操作することができる。システム起動の早い段階では、保存された符号の任意の部分の起動の前に、符号に対してＣＲＣ計算を行い、保存された符号と比較される。不一致の事象では、破損が検出され、置換バージョンがダウンロードされる。このＣＲＣ保護は、ソフトウェア全体に適用することができるか、または符号化モジュールに適用することができる。この方法では、破損符号を起動しようとすることはないであろう。このステップＥ２はまた、システムの整合性のケースでは、システム更新が要求されないことをチェックする。実際、あるケースでは、デコーダまたは任意の他の原因に対する常駐ソフトウェアの新しいバージョンの有用性の例として、アプリケーションは、新しい常駐ソフトウェアのダウンロードを要求することができる。一般的に、これは、要求されたソフトウェアバージョンの識別子（identifier）のような追加的に必要な情報とともに、メモリの既知のエリア内にダウンロードフラグを置くことを通じてなされる。更新の条件が、非整合性またはダウンロード要求に合致すると、常駐ソフトウェアバージョンは、既存のバージョンの置換として、メモリ内にダウンロードされ、格納される。このステップの終了の際に、デバイスは、常駐ソフトウェアの不可欠なバージョンを当然所有する。メモリ内に格納されたソフトウェアのコピーを作成する各バイトが、参照バージョン内の対応するバイトにマッチするとき、ソフトウェアは、不可欠なものとなると言える。これは、ハードウェアまたはソフトウェアのプロセスは値を修正せず、どんなバイトも破損しないことを意味する。

それから、ラベルＥ３の第二のステップでは、システムカーネルは、メモリにロードされ、起動される。次に、図中に示していないステップでドライバが起動されたあと、サービスは、システムカーネルによって、ロードされ、起動される。全てのサービスを起動するまで繰り返されるステップＥ８として示した他の起動のあとに、これらのサービスは、１つを起動する。一旦全てのサービスが起動されると、アプリケーションは、ステップＥ１０で起動される。デコーダは、それから、使用のために操作可能で作動可能となる。

ソフトウェア起動は、それゆえ、カーネル起動、サービスの起動、アプリケーションの起動に対応する三段階に分割することができる。これらの段階のそれぞれは、問題を実行することとなる。これらの段階のそれぞれの異なる特徴に依存すると、予測可能な修正の対策と同様に、エラーのタイプ、発生する可能性、システムのオペレーションの結果も異なる。

カーネル起動段階は、ハードウェア上で実行されるであろう最小ソフトウェアによって特徴づけられる。このソフトウェアは、一般的には、パラメータを考慮に入れることはないが、または限られた数の外部パラメータを考慮しない。それゆえ、一般的に、カーネルのオペレーションを網羅的にテストすることが可能である。我々は、オペレーションが比較的簡単なままで、適した環境で実行されるソフトウェアを有する。このポイントでエラーが発生する可能性は、それゆえ低く、一般的にはハードウェアの不具合またはフラッシュメモリに格納されたバージョンの破損によるものである。

サービス起動段階は、その一部が、より複雑な機能によって特徴付けられ、そのソフトウェアを網羅的な手法でテストすることがより難しいことを意味する。さらに、それらのモジュールの多くは、モジュールが起動されると、外部パラメータを使用する。例えば、チップカードに含まれる情報を用いるアクセス制御モジュールを、引用することができ、サービスコントローラのリストは、ネットワーク上のサービスのリストを検索、または前回の使用で保存されたリストを初期化することができる。モジュールにとって、前回の使用で保存されたユーザーパラメータを使用することもまた、ありふれたことであろう。サービスソフトウェアモジュールは、それゆえ、変化する環境で稼動する比較的複雑なプログラムである。結果として、全ての起こりうるパラメータ値に関してサービスソフトウェアモジュールを完全にテストすることは、一般的には、不可能である。サービスソフトウェアモジュールはまた、ハードウェアの不具合、またはメモリ中に格納されたソフトウェアの破損の犠牲となりうる。

アプリケーション起動段階に関しては、さらに変化する実行条件を伴う、より複雑なサービス起動段階として特徴付けられる。実際、アプリケーション起動段階の実行はまた、考慮しなければならない異なるパラメータに加えて、ユーザー、およびユーザーがデコーダに関して取り得る全てのアクションと相互作用しなければならない。アプリケーション起動段階はまた、ハードウェアの不具合、またはメモリ内に格納されたそのソフトウェアの破損を経験しうる。

エラーをより良く管理することを試みるために採用することができる異なる対策を、ここで説明する。

ハードウェアの不具合に関しては、ユーザーが修復のためにデバイスを操作しなければならないので、一般的には、すべきことはない。

カーネルが、ハードウェアの不具合および保存されたソフトウェアのイメージの破損によるエラーをこうむることが知られている。他のエラーリカバリーメカニズムが、一般的に、この符号化に対し、計画されることはない。

アプリケーションに関しては、実行において起こるソフトウェアの問題による妨害を検出するメカニズムをも有する。このメカニズムは、ウォッチドッグリセットとして知られ、システムに対しては、０まで減少するカウンターを初期化することから成る。アプリケーションは、定期的に、ウォッチドッグリセットのカウンターを、０に達することのない方法で増加させる。アプリケーションがフリーズすると、もはやカウンターを増加させることはできず、それゆえ、カウンターはゼロ値に達する。カウンターが値０に達すると、システムは、システムの再初期化、すなわちデコーダのリスタートをトリガする。このリスタートは、一般的には、デバイスの操作可能な状態を再確立するのに十分である。アプリケーションの操作段階において起こる問題は、一般的には、アプリケーションの使用または外部条件の出現によるものであり、リスタートは、問題に関する条件が消滅した新しい起動となる。

サービス起動段階は、メモリ内のソフトウェアの破損およびハードウェアの不具合を越えて、起動の問題を経験することができる。実際、これらのサービスは、一定の複雑性を有し、さらに、それらの起動は、サービスまたはユーザーの好みの最後のリストなどの外部パラメータに依存することができる。これらのモジュールは、起こりうる外部パラメータ値の全てを完全にテストすることはできない。結果として、起動中の妨害は発生しうる。これらの問題は、一般的には、デバイスをリスタートすることによっては解決することができず、このリスタートは、考慮に入れるパラメータを変化させない。パラメータは、モジュール実行エラーを引き起こし、毎回そのように行う。そのような状況では、始動されるデバイスは、モジュールが起動されると、エラーを経験するかもしれない。このエラーは、それから、デバイスのリスタートを引き起こす。エラーは、リスタートで再発生し、デバイスは、リスタートの中断しないサイクルに入る。

図１は、このタイプの状況を検出し修正の対策をとることを可能にする本発明の実施形態による始動ダイアグラムを表す。実施形態は、サービス起動段階において、スイッチングポイントを記憶する事実に基づく。この記憶は、「トレース」データをメモリに書き込むことによってなされる。この始動が成功した場合は、サービスの始動段階の終了の際に、これらのトレースは、メモリから削除される。しかしながら、サービスの１つの起動において問題が起きた場合は、これらのトレースが削除されると、ステージに達する前に、リスタートが生じる。この始動において、メモリ内のトレースの存在は、前回の始動が完了していなかったことを示す。さらに、トレースの値は、問題を引き起こしたサービスを識別することを可能にする。ステップＥ１では、デバイスが始動される。デバイスのソフトウェアの整合性を検証するステップＥ２が続き、必要な場合には、新しい常駐ソフトウェアをダウンロードする。次は、カーネルおよびドラーバーを起動するステップＥ３に続く。このステップＥ３の終了の際に、メモリに書き込まれたトレースの存在がチェックされる。トレースが存在しない場合、前回の始動は、成功であり、サービス起動プロセスが、開始される。この情報は、ステップＥ７で最初のトレースの形式に記憶される。最初のサービスは、それから、ラベルＥ８のステップによって起動される。次に、サービス起動プロセスの状態を毎回ステップＥ７に格納することによって、ステップＥ７およびＥ８は、繰り返される。この状態は、例えば、起動された最後のサービス、または起動されるであろう次のサービスに対する参照とすることができる。全てのサービスが起動されると、トレースは、ステップＥ９で削除される。このステップはまた、実施形態において、以下で説明する例外カウンター（anomaly counter）をリセットするであろう。次に、うまく起動されたサービス、すなわちアプリケーション起動ステップＥ１０は、デバイスの始動プロセスを終了させる。

サービスの起動が失敗すると、デバイスは、すぐにリスタートするか、または、デバイスブロックのあとのユーザーのコマンドでリスタートするかのいずれかである。任意のケースにおいては、このリスタートは、始動プロセスがトレース削除のステップＥ９を実行しうる前に発生する。したがって、リスタートの間、カーネル起動のステップＥ３の終了の際に実行されたトレース存在テストは、肯定的なものとなるであろう。このケースでは、ステップＥ４は、例外カウンターを増加させることから成る。このカウンターは、連続して失敗した始動の数をカウントするのに用いられる。トレースは、それからステップＥ５で削除されるであろう。これら２つのステップの順序は、重要ではない。テストは、しきい値（threshold）と比較して例外カウンターをテストするために行われる。このしきい値を超えている場合は、アラームをトリガし、修正するアクションをとることが可能である。しきい値テストと関係するこの例外カウンターの使用は、一定数の連続して失敗した始動がエラーを生成したあとにのみ、アラームをトリガすることを可能にする。この使用は、選択自由であり、実際、最初に失敗した始動からアラームをトリガすることができる。しかし、このケースでは、例えば、電源異常またはユーザーによって切られたデバイスなどの、始動プロセスにおける偶然の割り込みから問題が起こる場合、アラームをトリガすることができる。このしきい値に達しない限りは、ステップＥ７からＥ１０の実行を通して、始動が試みられるであろう。しきい値は、代表的には、３または５の単位である。高い方の値、すなわち、より失敗した始動は、アラームをトリガする必要があり、低い方の値は、偶然の問題に対するアラームをトリガするリスクがより高いであろう。

いくつかの種類の修正アクションは、可能である。最初の可能性は、デバイスをデフォルトの構成にリセットすることである。言い換えると、ユーザープロファイル、ユーザーの好み、サービスのリストなどの全てのパラメータは、デフォルト値にリセットされうる。この手法では、既知でありテストされた構成を取得し、始動が起こることを可能にする。不完全なサービスの起動を、非アクティブにすることもでき、デバイスは、１または複数の短いサービスをリスタートすることができる。これは、おそらく機能低下につながるが、ユーザーが問題を正すことを可能にすることができる。常駐ソフトウェアの新しいバージョンをダウンロードするための要求はまた、メモリに書き込まれ、デバイスを既知の状態にリセットすることができる。ユーザーに対し、メッセージを表示することができる。パラメータが初めにデフォルト値にリセットされると、リカバリーの方針を実装することもでき、成功しない場合には、いくつかのサービスを非アクティブにし、これらのアクションが失敗するケースでは、常駐ソフトウェアの新しいバージョンがダウンロード用に要求される。ユーザーが、オンスクリーンのメッセージまたはデバイス上の特定の信号のアクティベーションなどの他の通信手段によって、状況を知ることが望ましい。

このように説明した実施形態は、限定的なものではない。当業者は、応用が可能であることを理解されたい。特に、トレースを削除することは、サービス起動段階の前に問題を示す値で初期化されるであろうパラメータであって最後の始動が成功したことを示すパラメータを、書き込むことによって置き換えることができる。修正するアクションは、本発明の枠組みを逸脱することなく、複数の方法と結びつけることができることも明らかである。メモリに書き込まれたトレースの時間と内容を異にして選択することもできる。

本発明の実施形態による方法のフローチャートを示す図である。 本発明によるデバイスの実施形態を示す図である。 本発明によるデバイスの実施形態を示す図である。 フラッシュメモリに格納されたソフトウェアを起動するときの順序を示したフローチャートである。

Claims (15)

1. 永続メモリを備える電子デバイスの始動において起こるエラーを検出するための方法であって、前記電子デバイスが常駐ソフトウェアによって制御され、常駐ソフトウェアの始動プロセスが、少なくとも、
   初めの始動において、各モジュールが起動される前に情報を前記デバイスのメモリに書き込むための少なくとも１つのステップであって、前記始動プロセスが複数のモジュールの連続起動を伴うステップと、
   第二の始動において、前記第一の始動において前記メモリに書き込まれた前記情報に従って、前記第一の始動において起こったエラーを検出するステップと
   を備えることを特徴とする方法。
2. 前記常駐ソフトウェアの少なくとも一部のエラーフリーの起動が完了すると前記メモリに書き込まれた前記情報を削除するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記エラーを検出するステップは、前記始動プロセスにおいて前記メモリに書き込まれた前記情報の存在を検出することによってなされることを特徴とする請求項２に記載の方法。
4. エラーを生成した少なくとも１つの前回の始動の前記検出に続いてアラームをトリガすることをさらに備えることを特徴とする請求項１から請求項３のいずれか１つに記載の方法。
5. アラームがトリガされると、前記デバイスの少なくとも１つのパラメータの前記デフォルト値を再格納するステップをさらに備えることを特徴とする請求項４に記載の方法。
6. アラームがトリガされると、前記次のデバイスの始動において少なくとも１つのモジュールの前記起動を非アクティブにするステップをさらに備えることを特徴とする請求項４に記載の方法。
7. アラームがトリガされると、常駐ソフトウェアの新しいバージョンのダウンロードを引き起こすステップをさらに備えることを特徴とする請求項４に記載の方法。
8. アラームがトリガされると、前記ユーザーに対して情報の前記表示を引き起こすステップをさらに備えることを特徴とする請求項４に記載の方法。
9. 永続メモリと、電子デバイスを制御するように設計された常駐ソフトウェアと、常駐ソフトウェアが前記始動プロセスにおいて各モジュールの前記起動の前に情報を前記デバイスのメモリに書き込む手段を備えるデバイスの始動における常駐ソフトウェア起動手段であって、前記始動プロセスが複数のモジュールの連続起動を含む手段と、前記始動プロセスにおいてメモリに書き込まれた前記情報に従って、前記前回の始動において起こるエラーを検出する手段とを備えることを特徴とする電子デバイス。
10. 常駐ソフトウェアの少なくとも一部のエラーフリーの起動が完了すると前記メモリに書き込まれた前記情報を削除する手段をさらに備えることを特徴とする請求項９に記載のデバイス。
11. エラーを生成した少なくとも１つの前回の始動の前記検出に続くアラームをトリガする手段をさらに備えることを特徴とする請求項９または請求項１０のいずれか１つに記載のデバイス。
12. アラームがトリガされると、前記デバイスの少なくとも１つのパラメータの前記デフォルト値をリセットする手段をさらに備えることを特徴とする請求項１１に記載のデバイス。
13. アラームがトリガされると、前記次のデバイスの始動において、少なくとも１のモジュールの前記起動を非アクティブにする手段をさらに備えることを特徴とする請求項１１に記載のデバイス。
14. アラームがトリガされると、常駐ソフトウェアの新しいバージョンのダウンロードを引き起こす手段をさらに備えることを特徴とする請求項１１に記載のデバイス。
15. アラームがトリガされると、前記ユーザーに対して情報を表示する手段をさらに備えることを特徴とする請求項１１に記載のデバイス。

Images