(57)【特許請求の範囲】
【請求項１】
中央演算処理装置およびメモリからなるデータ処理装置において、
記録媒体の書き込みおよび読み出しを制御するドライバを有し、
コンポーネントから状態保存処理要求があると、スナップショットファイルを初期化し、状態保存の対象となる全てのコンポーネントから出力されるインデックスデータおよびスナップショットデータを上記スナップショットファイルとして上記記録媒体に保存し、保存された上記スナップショットファイルをクローズし、
状態復元処理要求があると、上記記録媒体に保存されている上記スナップショットファイルをオープンし、上記インデックスデータおよびスナップショットデータを読み込み、読み込まれた上記スナップショットデータに応じて全てのコンポーネントを起動し、起動された上記コンポーネントの状態を復元するようにしたことを特徴とするデータ処理装置。
【請求項２】
上記スナップショットファイルは、上記コンポーネント名でタグ付けされていることを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
上記状態保存処理および上記状態復元処理は、上記コンポーネント毎の特定のアドレスに存在する関数を呼び出すようにしたことを特徴とする請求項１に記載のデータ処理装置。
【請求項４】
上記記録媒体は、携帯可能な記録媒体としたことを特徴とする請求項１に記載のデータ処理装置。
【請求項５】
上記スナップショットファイルがオープンされた後、データベースをオープンし、
上記スナップショットファイルがクローズされた後、上記データベースをクローズすることを特徴とする請求項１に記載のデータ処理装置。
【請求項６】
上記コンポーネント自身によって上記コンポーネント間の依存関係をデータベースに登録することを特徴とする請求項１に記載のデータ処理装置。
【請求項７】
中央演算処理装置およびメモリからなるデータ処理方法において、
ドライバによって記録媒体の書き込みおよび読み出しを制御し、
コンポーネントから状態保存処理要求があると、スナップショットファイルを初期化し、状態保存の対象となる全てのコンポーネントから出力されるインデックスデータおよびスナップショットデータを上記スナップショットファイルとして上記記録媒体に保存し、保存された上記スナップショットファイルをクローズし、
状態復元処理要求があると、上記記録媒体に保存されている上記スナップショットファイルをオープンし、上記インデックスデータおよびスナップショットデータを読み込み、読み込まれた上記スナップショットデータに応じて全てのコンポーネントを起動し、起動された上記コンポーネントの状態を復元するようにしたことを特徴とするデータ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、システムの突発的な電源切断に対応することができるデータ処理装置および方法に関する。
【０００２】
【従来の技術】
従来、コンピュータで制御されるシステムに突発的な電源切断が発生した場合、全くの初期状態から起動を行う再起動と、データとして保存しておいた動作中のメモリ状態を全て読み込んで実行を継続するハイバネーションとの何れか一方が行われていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、再起動の場合、一般的にデバイスの検出や初期化など全ての処理を行うために時間がかかる問題があった。一方、ハイバネーションの場合、実行しているプログラムや使用中のメモリ量と無関係にメモリ情報を書き出すため、メモリ状態をデータとして保存する時および復帰する時に時間がかかる問題があった。さらに、ハイバネーションは、何らかの処理中にバックグラウンドで実行するようなことはできず、突発的な電源切断に対処することはできない問題もあった。
【０００４】
これに対して、瞬電などの突発的な電源切断に対処する方法としては、低電圧状態を検出してアプリケーションに終了処理をさせる方法がある。しかしながら、これは電圧状態の検出回路が必要であり、また電圧状態の検出回路を設けても、低電圧状態の発生から電源切断までの時間で、全てのデータの保存が可能か否かをシステムソフトウェア側が保証することはできないという問題があった。
【０００５】
しかしながら、この方法は、あくまで電源切断に対する対策であるため、復帰時については、再起動と全く同様であり、利用可能状態になるまでには、時間がかかる問題があった。
【０００６】
従って、この発明の目的は、システムに突発的な電源切断が発生しても瞬時に電源切断直前の状態に戻ることができるデータ処理装置および方法を提供することにある。
【０００７】
【課題を解決するための手段】
請求項１に記載の発明は、中央演算処理装置およびメモリからなるデータ処理装置において、記録媒体の書き込みおよび読み出しを制御するドライバを有し、コンポーネントから状態保存処理要求があると、スナップショットファイルを初期化し、状態保存の対象となる全てのコンポーネントから出力されるインデックスデータおよびスナップショットデータをスナップショットファイルとして記録媒体に保存し、保存されたスナップショットファイルをクローズし、状態復元処理要求があると、記録媒体に保存されているスナップショットファイルをオープンし、インデックスデータおよびスナップショットデータを読み込み、読み込まれたスナップショットデータに応じて全てのコンポーネントを起動し、起動されたコンポーネントの状態を復元するようにしたことを特徴とするデータ処理装置。である。
【０００８】
請求項７に記載の発明は、中央演算処理装置およびメモリからなるデータ処理方法において、ドライバによって記録媒体の書き込みおよび読み出しを制御し、コンポーネントから状態保存処理要求があると、スナップショットファイルを初期化し、状態保存の対象となる全てのコンポーネントから出力されるインデックスデータおよびスナップショットデータをスナップショットファイルとして記録媒体に保存し、保存されたスナップショットファイルをクローズし、状態復元処理要求があると、記録媒体に保存されているスナップショットファイルをオープンし、インデックスデータおよびスナップショットデータを読み込み、読み込まれたスナップショットデータに応じて全てのコンポーネントを起動し、起動されたコンポーネントの状態を復元するようにしたことを特徴とするデータ処理方法。である。
【０００９】
コンポーネントから状態保存処理要求が出力されると、コンポーネントの依存関係および／または保存データがスナップショットファイルとして記録媒体に記録される。電源切断が発生したときに、コンポーネントの依存関係に従って、記録媒体に記録されているスナップショットファイルからコンポーネントの状態復元を行う。
【００１０】
【発明の実施の形態】
以下、この発明の一実施形態について図面を参照して説明する。なお、各図に亘り同じ機能を有するものには、同一の参照符号を付し、説明の重複を避ける。図１は、この発明が適用されるシステムの一実施形態の概略を示す。この図１に示すシステムは、ＣＰＵ（Central Processing Unit）１、ＲＡＭ（Random Access Memory）２、デバイス３、不揮発メモリ４およびバス５から構成される。
【００１１】
ＲＡＭ２は、書き込み／読み出しが自由なメモリである。デバイス３は、例えばシリアルデバイスやグラフィックデバイスなどであり、不揮発メモリ４は、フラッシュＲＯＭやディスクなどの不揮発記憶デバイスである。また、不揮発メモリ４は、フラッシュメモリカードなどの取り外し可能なデバイス（メディア）、いわゆるＩＣカードであっても良い。ＣＰＵ１は、これらＲＡＭ２、デバイス３および不揮発メモリ４は、バス５を介して接続され、相互に通信可能な状態とされる。また、バス５は、ネットワークであっても良い。
【００１２】
この発明の機能別コンポーネントの初期化の制御を図２に示すフローチャートを参照して説明する。ステップＳ１では、アプリケーションやデバイスドライバなどの機能別コンポーネント（以下、単にコンポーネントと称する）は、起動された際に、内部変数の初期化が行われる。ステップＳ２では、コンポーネント自身によって状態保存データベースにコンポーネント間の依存関係が登録される。後述するシステムの状態保存処理の際には、この状態保存データベースに登録されているコンポーネントが状態保存の対象と見なされる。このように、この図２に示すフローチャートは、アプリケーションやデバイスドライバなどが起動した時の初期化動作を示す。
【００１３】
システムの状態保存処理を図３を参照して説明する。この図３は、ＣＰＵ１からアクセス可能なメモリ上に存在し、ＣＰＵ１が実行するモジュール間の関係を示している。アプリケーション１４の中のあるアプリケーションから本モジュール１１内のチェックポイントマネージャ１２に対して、状態保存処理要求が出力される。チェックポイントマネージャ１２は、アプリケーション１４やデバイスドライバ１５などのコンポーネントに対してスナップショット出力を行うように要求が出力される。この要求が出力される順序は、本モジュール１１内の状態保存データベース１３に登録されている順序に従う。この状態保存データベース１３に登録されている順序がコンポーネント間の依存関係を表している。
【００１４】
各コンポーネントがスナップショット出力の要求を受け取ると、チェックポイントマネージャ１２を介して不揮発メモリドライバ１６に対してコンポーネント毎の特定のアドレスに存在する関数が呼び出され、コンポーネントの状態をスナップショットデータとして出力する。各コンポーネントのスナップショットデータの出力が終了した時点で、出力された全てのスナップショットデータが図４に示すようなスナップショットファイルとされ、不揮発メモリドライバ１６によって記録媒体（図示なし）に保存される。不揮発メモリドライバ１６は、さまざまな記録媒体、例えば不揮発性メモリカードの書き込み／読み出しをサポートしている。そして、状態保存処理要求を出力したアプリケーション１４に処理が戻る。
【００１５】
スナップショットファイルは、図４に示すようにコンポーネント名（文字列）でタグ付けされ、例えばインデックスファイルと、データファイルとの組み合わせとして不揮発メモリドライバ１６によって記録媒体に保存される。インデックスファイルのフォーマットの一例を図４Ａに示し、データファイルのフォーマットの一例を図４Ｂに示す。図４Ａに示すように、インデックスファイルには、コンポーネント名と、それに対応するデータのデータファイル中におけるオフセット位置が格納される。図４Ｂに示すように、データファイルには、各コンポーネントが出力したスナップショットデータが１つのファイルに連結して格納される。
【００１６】
このように、システムの状態保存処理は、アプリケーション実行中の任意のタイミングまたはシステムやアプリケーションから指定された周期毎に起動される。一度、状態保存処理が起動されると、その処理が終了するまで次の状態保存処理要求は待たされる。
【００１７】
不揮発メモリドライバ１６によって記録媒体に記録されるスナップショットファイルは、状態保存データベース１３に登録されている順序に従って登録されているので、コンポーネント間の依存関係が反映されている。
【００１８】
図５にシステムの状態保存処理の一例のフローチャートを参照して説明する。ステップＳ１１では、スナップショットファイルの初期化が行われる。ステップＳ１２では、状態保存データベース１３がオープンされる。ステップＳ１３では、状態保存の対象となるコンポーネントが存在するか否かが判断される。状態保存データベース１３に登録されている順番に従って、まだ状態保存の対象となるコンポーネントが存在すると判断した場合、ステップＳ１４へ制御が移り、状態保存の対象となるコンポーネントが存在しないと判断した場合、ステップＳ１６へ制御が移る。
【００１９】
ステップＳ１４では、状態保存の対象となるコンポーネントからインデックスデータがチェックポイントマネージャ１２を介して不揮発メモリドライバ１６に出力される。ステップＳ１５では、状態保存の対象となるコンポーネントからスナップショットデータがチェックポイントマネージャ１２を介して不揮発メモリドライバ１６に出力される。
【００２０】
ステップＳ１６では、不揮発メモリドライバ１６によって記録媒体に格納されたスナップショットファイルがクローズされる。ステップＳ１７では、保存状態データベース１３がクローズされる。
【００２１】
システムの状態復元処理を図６を参照して説明する。この図６は、ＣＰＵ１からアクセス可能なメモリ上に存在し、ＣＰＵ１が実行するモジュール間の関係を示している。システムのブート部１７からチェックポイントマネージャ１２に対して状態復元処理要求が出力される。この状態復元処理要求によって、チェックポイントマネージャ１２は、不揮発メモリドライバ１６に対してスナップショットファイルの読み込みを要求する。上述したようにスナップショットファイルは、コンポーネント間の依存関係が反映されている。チェックポイントマネージャ１２は、スナップショットファイルに格納されたコンポーネント名から状態復元すべきアプリケーション・デバイスドライバ１８のコンポーネントを検索し、まず必要で有ればそのコンポーネントを読み込み、起動する。
【００２２】
そして、コンポーネントが保持しているシンボル情報から呼び出すべき関数のアドレスを不揮発メモリドライバ１６を介して記録媒体から取得し、そのアドレスから関数を呼び出す。呼び出される関数は、コンポーネント毎の特定のアドレスに存在するものである。これらの処理を、スナップショットファイルに保存されている全てのコンポーネントについて実行する。なおこの際、コンポーネント自身によって本モジュール１１内の状態保存データベース１３にコンポーネント間の依存関係が登録される。この状態保存データベース１３に登録された内容は、以後の状態保存処理要求の際に参照される。
【００２３】
なお、状態復元処理は、システムのブート時だけでなく、任意のタイミングで可能である。ただし、一度、状態復元処理が起動されると、その状態復元処理が終了するまで、次の状態復元処理要求は待たされる。
【００２４】
図７にシステムの状態復元処理の一例のフローチャートを参照して説明する。ステップＳ２１では、不揮発メモリドライバ１６によって記録媒体に格納されているスナップショットファイルがオープンされる。ステップＳ２２では、状態保存データベース１３がオープンされる。ステップＳ２３では、不揮発メモリドライバ１６によって記録媒体に格納されているインデックスデータが読み込まれる。ステップＳ２４では、格納されているインデックスデータに基づいて、読み込む必要のあるコンポーネントは終了したか否かが判断される。インデックスデータに基づいて、まだ読み込む必要のあるコンポーネントの読み込みが終了していないと判断されると、ステップＳ２５へ制御が移り、読み込む必要のあるコンポーネントの読み込みが全て終了していると判断されると、ステップＳ２９へ制御が移る。
【００２５】
ステップＳ２５では、不揮発メモリドライバ１６を介して記録媒体から格納されているスナップショットデータが読み込まれる。ステップＳ２６では、読み込まれたスナップショットデータに応じてコンポーネントが読み込まれ、起動される。ステップＳ２７では、状態復元処理が行われる。具体的には、コンポーネントが保持しているシンボル情報から読み出すべき関数のアドレスが取得され、そのアドレスから関数が呼び出される。呼び出される関数は、コンポーネント毎の特定のアドレスに存在するものである。ステップＳ２８では、コンポーネント自身によって本モジュール１１内の状態保存データベース１３にコンポーネント間の依存関係が登録される。そして、制御はステップＳ２３へ戻る。
【００２６】
ステップＳ２９では、不揮発メモリドライブ１６によって記録媒体に格納されているスナップショットファイルがクローズされる。ステップＳ３０では、状態保存データベース１３がクローズされる。
【００２７】
この実施形態では、システム上でアプリケーションが動作していても、そのシステムを操作している操作者が知ることなく、そのバックグラウンドで状態保存を実行することができる。
【００２８】
この実施形態は、図１に示す構成で有ればどのようなものにも適応することができる。例えば、携帯電話、ＰＤＡ（Personal Digital Assistants）、ノートＰＣなどに適用することができる。
【００２９】
この実施形態では、不揮発メモリドライバ１６によってスナップショットファイルが格納されている記録媒体、例えばＩＣカードを、スナップショットファイルを格納したＰＣと異なるＰＣに装着し、状態復元処理を行うと、スナップショットファイルを格納したＰＣと全く同じ環境で、ＩＣカードを装着したＰＣを使用することができる。
【００３０】
【発明の効果】
この発明に依れば、電源の再投入時に、デバイスの依存関係に従いつつ起動し、高速に状態を復元することができる。
【００３１】
さらに、この発明に依れば、あるコンポーネントの状態復元のために必要なデータをコンポーネント自身が待避・復元するため、必要最小限の非常に少ないデータ量で実現することができる。
【００３２】
また、この発明に依れば、復元のための情報を携帯型メモリデバイスに保存することで、他の機器にそのメモリデバイスを接続すれば高速に状態を復元することができる。
【００３３】
さらに、この発明に依れば、システムのブート時に限らず、任意のタイミングで状態復元を行うことができる。
【図面の簡単な説明】
【図１】この発明を適用することができるシステムのブロック図である。
【図２】この発明のコンポーネントの初期化の一例を説明するためのフローチャートである。
【図３】この発明のモジュール間の関係を説明するための略線図である。
【図４】この発明のスナップショットファイルのフォーマットの一例である。
【図５】この発明の状態保存処理の一例を説明するためのフローチャートである。
【図６】この発明のモジュール間の関係を説明するための略線図である。
【図７】この発明の状態復元処理の一例を説明するためのフローチャートである。
【符号の説明】
１１・・・本モジュール、１２・・・チェックポイントマネージャ、１３・・・状態保存データベース、１４・・・アプリケーション、１５・・・ドライバ、１６・・・不揮発メモリドライバ、１７・・・ブート部、１８・・・アプリケーション・ドライバ
【図１】
0004407043.tif 000002
【図２】
0004407043.tif 000003
【図３】
0004407043.tif 000004
【図４】
0004407043.tif 000005
【図５】
0004407043.tif 000006
【図６】
0004407043.tif 000007
【図７】
0004407043.tif 000008