JP2008003770A - 携帯端末 - Google Patents

Abstract

【課題】オペレーティングシステムが不安定状態となった場合でも、その不安定状態で生じる不具合を未然に回避することができる携帯端末を提供する。
【解決手段】監視スレッド（１），（２）……は、一定時間毎に動作情報を動作状況監視フラグの対応するフラグをセットする。診断プログラムを備えた割り込み処理は、一定間隔で動作状況監視フラグをチェックし、セットされないフラグがあった場合は、異常を報知する。また、ＯＳが不安定であると判断し、重要な情報をＲＡＭ４からフラッシュメモリ５に退避してから、ＯＳにリセット要求を指令する。ＯＳが再起動したときは、重要な情報をＲＡＭ４に復帰する。
【選択図】図１

Description

本発明は、オペレーティングシステムによりアプリケーションの動作を管理する携帯端末に関する。

例えばパソコンのＯＳ（Operating System）では、メモリリークなどの不安定要因により、急激に処理速度が低下したり、処理が停止（ロック）したりする場合がある。メモリリークとは、パソコンの動作中に、使用可能なメモリ容量がだんだん減っていく現象で、システムの性能が低下したり、不安定になったりすることの要因となる。
特開平９−１７９７５４号公報

特許文献１のものでは、コンピュータ上で実行するユーザ定義タスクの各種外乱による停止時間が許容時間を超過した場合に、ユーザ定義タスクに事象を通知するようにしている。従って、ユーザ定義タスクは、外乱による実行遅れを知ることができるので、対処することが可能となる。

ところで、物流情報或いは在庫情報を管理するための携帯端末にもＯＳが搭載されており、アプリケーション及びドライバの動作を管理しているものの、ＯＳが不安定要因により、システムの性能が低下したり、不安定となったりした場合に、特許文献１のものでは、これまで内部に蓄積していたデータが消失したり、業務が停止したりする障害が発生する虞がある。

本発明は上記事情に鑑みてなされたもので、その目的は、オペレーティングシステムが不安定状態となった場合でも、その不安定状態で生じる不具合を未然に回避することができる携帯端末を提供することにある。

請求項１の発明によれば、オペレーティングシステムが何らかの要因で不安定状態となると、予測手段が各種診断結果に基づいてオペレーティングシステムは不安定状態となったと予測するようになる。すると、回避策実行手段が予測された不安定状態に応じた所定の回避策を実行するようになるので、不安定状態による不具合を未然に回避する。

請求項２の発明によれば、複数の監視スレッドは、自己に対応する動作状況監視フラグを定期的にセットしている。アプリケーションまたはドライバの各スレッドの動作が不安定状態となると、そのスレッドの優先順位よりも低い監視スレッドが自己に対応する動作状況監視フラグをセットできなくなる。診断プログラムは、動作状況監視フラグを割り込み処理により定期的に監視しており、所定時間内に更新されない動作状況監視フラグがある場合は、そのフラグを更新する監視スレッドより優先順位が同一または上位に設定されたスレッドが不安定状態となったと判断する。

請求項３の発明によれば、複数の監視スレッドは、動作状況を最優先監視スレッドに定期的に通知している。最優先監視スレッドは、監視スレッドからの動作状況の通知を定期的にチェックしており、所定時間内に動作状況を通知しない監視スレッドがあった場合は、その監視スレッドより優先順位が同一または上位に設定されたスレッドが不安定状態となったと判断する。

請求項４の発明によれば、アプリケーションまたはドライバなどの各スレッドが不安定状態となった場合は、このスレッドよりも優先順位が低い監視スレッドが最優先監視スレッドに動作状況を通知できなくなることから、通知できない監視スレッドの優先順位に基づいて不安定状態となったスレッドを判断することが可能となる。

請求項５の発明によれば、ユーザは、不安定状態と判断する時間を任意に設定することができる。
アプリケーションやドライバなどの各スレッドがメモリリークを生じると、スレッドの動作が不安定状態となると共に、スレッドが使用するメモリ使用サイズが通常よりも大きくなる。このような場合、請求項６の発明によれば、監視スレッドは、提供手段に対して各スレッドのメモリ使用サイズを定期的に問合せ、その応答により各スレッドのメモリ使用サイズを取得し、当該メモリ使用サイズが所定メモリサイズを越えた場合は、不安定状態となったと判断する。

請求項７の発明によれば、監視スレッドは、提供手段に対してスレッド全体のメモリ使用サイズを定期的に問合せ、その応答によりスレッド全体のメモリ使用サイズを取得し、当該メモリ使用サイズが所定メモリサイズを越えた場合は、不安定状態となったと判断する。

請求項８の発明によれば、ユーザは、不安定状態と判断する時間を任意に設定することができる。
オペレーティングシステムが不安定状態となると、ユーザが必須機能を動作させるように操作させようとするものの、必須機能が動作しないことがある。このような場合、請求項９の発明によれば、必須スレッドは、自己に対応する動作状況監視フラグをセットしなくなる。診断プログラムは、動作状況監視フラグを割り込み処理により定期的に監視しており、所定時間内に更新されない動作状況監視フラグがある場合は、当該動作状況監視フラグを更新する必須スレッドが不安定状態となったと判断する。

請求項１０の発明によれば、オペレーティングシステムが不安定状態となると、必須スレッドは、動作状況を監視スレッドに通知しなくなる。監視スレッドは、必須スレッドからの動作状況の通知を定期的にチェックしており、所定時間内に動作状況を通知しない必須スレッドがあった場合は、当該必須スレッドが不安定状態となったと判断する。

請求項１１の発明によれば、ユーザは、不安定状態と判断する所定時間を任意に設定することができる。
請求項１２の発明によれば、監視スレッドは、検査用プログラムを定期的に動作させ、その検査用プログラムの開始から終了までに要した時間を動作時間結果エリアに格納している。診断プログラムは、動作時間結果エリアを定期的に監視しており、監視スレッドの動作速度を求め、当該動作速度が所定速度より遅い場合は、不安定状態となったと判断する。

請求項１３の発明によれば、監視スレッドは、検査用プログラムを定期的に動作させ、その検査用プログラムの開始から終了までに要した時間を最優先監視スレッドに通知している。オペレーティングシステムが不安定となると、検査プログラムの動作速度が遅くなる。最優先監視スレッドは、監視スレッドからの時間通知を定期的にチェックし、検査用プログラムの動作速度を求め、当該検査用プログラムの動作速度が所定速度より遅い場合は、不安定状態となったと判断する。

請求項１４の発明によれば、ユーザは、オペレーティングシステムが不安定状態となったと判断する所定速度を任意に設定することができる。
請求項１５の発明によれば、ユーザは、オペレーティングシステムが不安定状態となったことを認識することが可能となる。

請求項１６の発明によれば、オペレーティングシステムが不安定状態となったときは、オペレーティングシステムを自動的にリセットすることができるので、面倒な操作を行うことなくオペレーティングシステムの不安定状態を解消することができる。
請求項１７の発明によれば、オペレーティングシステムがリセットされるのに先立って所定データを退避させることができるので、重要なデータが消失してしまうことを防止できる。
請求項１８の発明によれば、ユーザは、退避する所定データを任意に設定することができる。

以下、本発明を携帯型読取情報端末に適用した実施例について図面を参照して説明する。
図１は、本発明に係る携帯型読取情報端末のハードウェアとソフトウェアの構成を概略的に示している。この図１において、携帯型読取情報端末（携帯端末に相当）１は、ＣＰＵ２を主体として構成されており、プログラム及びアプリケーション並びにドライバなどのソフトウェア記憶用のＲＯＭ３、ワークデータ記憶用のＲＡＭ４、データ退避用のフラッシュメモリ５などが設けられている。また、携帯型読取情報端末１の上面には、操作部６及び表示器７が設けられている。
携帯型読取情報端末１のソフトウェアは、アプリケーション、オペレーティングシステム（以下、ＯＳ）、各ドライバ、割り込み処理とから構成されており、ＯＳにより各ソフトウェアの動作が管理されている。

さて、本実施例の携帯型読取情報端末１には、急激な処理速度の低下や処理の停止（ロック）を事前に予測するために、実施例に対応して以下の予測手段及び回避策実行手段として機能する診断プログラムを搭載している。この診断プログラムは、アプリケーション、ドライバ、割り込み処理に分散して搭載されており、連携して動作するようになっている。

診断プログラム（ａ）……ＯＳが割当てる処理の優先レベル毎に停止しているかを診断する。
診断プログラム（ｂ）……ドライバやユーザプログラムが確保しているメモリサイズを定期的に診断する。
診断プログラム（ｃ）……携帯型読取情報端末１に搭載している必須の機能が動作しているかどうかを診断する。
診断プログラム（ｄ）……ＯＳが割当てる処理の優先レベル毎に処理速度を診断する。

携帯型読取情報端末１は、これらの診断プログラムの組合せに基づいて決められた条件を満たしたと判断したとき、後述するように停止が近い或いは停止状態などを判断し、警告を表示したり、自動リセットしたりするようになっている。

以下、上記の診断プログラム（ａ）〜（ｄ）を実行するための実施例を順に説明する。
（第１実施例）
上記診断プログラム（ａ）を説明する第１実施例について図２ないし図９を参照して説明する。図２は、携帯型読取情報端末１のソフトウェア構成を示す概略図である。この図２において、ＯＳ８は、例えばWindows（登録商標） CEである。このWindows CEはＰＤＡ（Personal Digital Assistant）、或いは組み込み機器向けリアルタイムＯＳであり、対象となる装置に組込んで使用することを前提としたＯＳである。ドライバスレッド９、ユーザスレッド１０、監視スレッド１１は、それぞれプログラムである。スレッドとは、マルチスレッドに対応したＯＳ上で１つのアプリケーションの処理を複数に分割して実行する場合のソフトウェアの実行単位（タスク）である。高度な処理を行なうアプリケーションソフトなどでは、スレッドを複数走らせることにより、同時に複数の処理が実行可能となる。

ドライバスレッド９は、周辺機器を動作させるためのソフトウェアである。つまり、周辺機器の仕様や制御方法は製品によって大きく異なるため、ＯＳ８が単独ですべての製品をサポートすることはできないことから、ドライバスレッド９によりＯＳ８が周辺機器を制御するための橋渡しを行なう。

ユーザスレッド１０は、アプリケーションプログラムを構成するスレッドで、各スレッドがイベントに応じて動作することによりアプリケーションプログラムとして機能する。
上記診断プログラム（ａ）は、監視スレッド１１と割り込み処理１２とから構成されている。

監視スレッド１１は、ＯＳ８が割り当てる処理の優先レベルに対応して設けられている。つまり、例えばWindows CE 3.0では、２５６段階の優先レベルの割り込みをサポートしており、動作可能な複数の優先順位のスレッドがある場合、優先順位の高いスレッドが優先的に実行され、優先順位の低いスレッドは、優先順位の高いスレッドの実行が終了してから実行されるようになっている。本実施例では、このスレッドの優先順位を利用して、２５６段階の優先順位０〜２５５に対応して２５６の監視スレッド（以下、優先順位０の監視スレッドを監視スレッド（１）、優先順位１の監視スレッドを監視スレッド（２）、……、優先順位ｎ−１の監視スレッドを監視スレッド（ｎ）と称する）を作成し、各監視スレッド１１によりＲＡＭ４上の動作状況監視フラグ（図３参照）のうち自己に対応するフラグを定期的（一定時間毎）にセットするようになっている。このような動作状況監視フラグのセットは、ＯＳ８に対する割り込み処理により行われる。
尚、アプリケーション或いはドライバのスレッドに設定する優先順位として、複数のスレッドに同一の優先順位を設定することは可能である。

割り込み処理１２は、動作状況監視フラグを割り込み処理により定期的に監視し、予め決められた所定時間内に更新されない動作状況監視フラグがある場合は、その動作状況監視フラグ（以下、監視スレッド（１）に対応した動作状況監視フラグを動作状況監視フラグ（１）、監視スレッド（２）に対応した動作状況監視フラグを動作状況監視フラグ（２）、……、監視スレッド（ｎ）に対応した動作状況監視フラグを動作状況監視フラグ（ｎ）と称する）を更新する監視スレッド１１より優先順位が同一または上位のスレッドで停止したと判断するようになっている。この場合、予め決められた所定時間は、アプリケーション或いはユーザにより任意に設定可能となっている。

次に、上記構成の作用について説明する。
ユーザが携帯型読取情報端末１の電源を投入すると、ＯＳ８が起動する。このとき、ＯＳ８は、ドライバスレッド９及び監視スレッド１１を起動する。これにより、ＯＳ８は、ドライバスレッド９を通じて周辺回路とデータ通信が可能となる。また、監視スレッド１１は、動作状況監視フラグ（１），（２）……を定期的にセットする。

図４は、各監視スレッド（１），（２）……の動作を示している。この図４に示すように、例えば監視スレッド（３）は、自己に対応する動作状況監視フラグ（３）をセットしてから、指定時間待機するという動作を繰返すようになっている。また、例えば監視スレッド（２５２）は、自己に対応する動作状況監視フラグ（２５２）をセットしてから、指定時間待機するという動作を繰返すようになっている。これにより、各監視スレッド（１），（２）……の動作により動作状況監視フラグ（１），（２）……のうちの対応するフラグが一定時間毎にセットされるようになる。

ユーザが所望のアプリケーションプログラムを起動すると、ＯＳ８は、キー操作などのイベントの発生に応じてアプリケーションプログラムに対応したユーザスレッド１０（以下、優先順位０のユーザスレッドをユーザスレッド（１）、優先順位１のユーザスレッドをユーザスレッド（２）、……、優先順位ｎのユーザスレッドをユーザスレッド（ｎ）と称する）を起動したり、周辺機器に対応してドライバスレッド９（以下、優先順位０のドライバスレッドをドライバスレッド（１）、優先順位１のドライバスレッドをドライバスレッド（２）、……、優先順位ｎのドライバスレッドをドライバスレッド（ｎ）と称する）を起動したりすることによりアプリケーションプログラムを実行する。このようなアプリケーションプログラムとしては、商品に貼付されたラベルのコード読取りによる棚卸管理或いは在庫管理である。

図３は、ＯＳ８が起動したプログラムの優先順位を示している。この図３に示すように、監視スレッド（１）及びユーザスレッド（１）並びにドライバスレッド（１）の優先度（優先順位０）が最も高く、次に監視スレッド（２）及びユーザスレッド（２）並びにドライバスレッド（２）の優先度（優先順位１）が続いて設定されている。同様に、優先度（ｎ）に対応して監視スレッド（ｎ＋１）及びユーザスレッド（ｎ＋１）並びにドライバスレッド（ｎ＋１）が設定されている。

ここで、割り込み処理１２は、一定間隔で動作する割り込みにより動作状況監視フラグがセットされているかを一定間隔でチェックしている。
図５は、割り込み処理１２の動作のうち診断プログラムとしての動作を示すフローチャートである。この図５に示すように、割り込み処理１２は、ｎ＝１を設定してから（Ｓ１）、監視スレッド（１）の動作状況監視フラグ（１）のフラグがセットされているかを判断する（Ｓ２）。このとき、フラグがセットされているときは（Ｓ３：ＹＥＳ）、監視スレッド（１）は正常に動作していると判断し、監視スレッド（１）の動作状況監視フラグをリセットする（Ｓ４）。

次に、ｎ＝ｎ＋１によりｎ＝２を設定してから（Ｓ５）、ｎ＝２５６かを判断し（Ｓ６）、ｎ＝２５６でないときは（Ｓ６：ＮＯ）、ステップ（Ｓ２）に移行して上述した動作を繰返す。そして、ｎ＝２５６となったときは（Ｓ６：ＹＥＳ）、この後、指定時間後に割り込みが発生するように設定する。指定時間後に割り込みが発生すると、Ｓ１からの動作を繰返す。

さて、何れかのユーザスレッド１０または何れかのドライバスレッド９が何らかの要因により停止（ロック）すると、同一の優先順位が設定された監視スレッド１１が起動されなくなることから、その監視スレッド１１により動作状況監視フラグがセットされなくなる。このようにスレッドが動作状況監視フラグのセット状態を更新しなくなった場合は、割り込み処理１２は、図５に示すステップＳ３において、動作状況監視フラグがセットされていないと判断し（Ｓ３：ＮＯ）、優先順位の処理で問題が発生したと判断する（Ｓ８）。

監視スレッド１１は、上述したように割り込み処理１２が優先順位の処理で問題が発生したと判断したときは、ロックリセット条件が成立したと判断し、図６に示すように携帯型読取情報端末１の表示器７に「ロック警告」というメッセージを表示する。従って、ユーザは、アプリケーションまたはドライバの何れかのスレッドがロックしたことを認識することができる。尚、このようなロック判断としては、特定の優先順位の監視スレッド１１が動作しなくなることにより判断するようにしてもよい。

監視スレッド１１は、上述のように割り込み処理１２がスレッドはロックしたと判断したときは、図７に示すようにＲＡＭ４に記憶されている重要情報（機器固有の情報、携帯型読取情報端末１を起動するための情報など）を、図８に示すようにフラッシュメモリ５に退避（コピー）させてから、ＯＳ８に対してリセット要求を指令する。

ＯＳ８は、監視スレッド１１によりリセット要求が指令されたときは、ソフトリセットを実行することにより再起動する。これにより、不安定状態となったスレッドを含む全てのスレッドがリセットされて再起動されるので、スレッドは安定状態で動作するようになる。

そして、ＯＳ８は、再起動したときは、図９に示すようにフラッシュメモリ５に退避した重要情報をＲＡＭに復帰させる。
以上の動作により、ＯＳ８がリセットされるにしても、重要情報がクリアされてしまうことを防止できるので、ユーザは、携帯型読取情報端末１による作業を中断した作業から続行することができる。

このような実施例によれば、携帯型読取情報端末１のＯＳ８が起動したときは、優先順位が設定された監視スレッド１１を起動して動作状況監視フラグを一定間隔でセットすると共に、割り込み処理１２により動作状況監視フラグの状態を監視し、不安定となったと判断したときは、ＯＳ８をリセットすることにより自動復帰するようにしたので、ユーザが特別な操作を実行する必要はなく、使い勝手に優れている。
また、ＯＳ８をリセットする場合は、保存されている重要情報をフラッシュメモリ５にコピーし、ＯＳ８が立上ってから重要情報をＲＡＭ４に復帰するようにしたので、携帯型読取情報端末１による作業を継続することができる。

さらに、ＯＳ８が不安定となったときは、そのことをユーザに報知するようにしたので、ユーザは、ＯＳ８が不安定となったことを認識することができ、その要因を解消するように対処することが可能となる。この場合、不安定となった監視スレッド１１を報知するようにすれば、ロックしたアプリ／ドライバスレッドを予測することが可能となり、対処が容易となる。

（第２実施例）
次に、上記診断プログラム（ａ）を説明する第２実施例について図１０及び図１１を参照して説明するに、第１実施例と同一構成には同一符号を付して説明を省略し、異なる点について説明する。

ソフトウェア構成を示す図１０において、診断プログラムは、複数の監視スレッド（１），（２）……と、これらの監視スレッド（１），（２）……を監視するための最優先監視スレッドとからなる。各監視スレッド（１），（２）……は、動作状況を最優先監視スレッドに定期的に通知する。

ユーザスレッド１０及びドライバスレッド９の優先度は、第１実施例と同様に、何れかの監視スレッド１１の優先度と同一となるように設定されている。
最優先監視スレッドは、各監視スレッド（１），（２）……からの動作状況の通知を定期的にチェックし、決められた所定時間内に動作状況を通知しない監視スレッド（１），（２）……があった場合、その監視スレッド（１），（２）……より優先順位と同一または上位のスレッドでロックしたと判断してユーザに報知する。この場合、予め決められた所定時間は、アプリケーション或いはユーザにより任意に設定可能となっている。
また、ロックしたことを判断した場合は、ＲＡＭ４に記憶されている重要情報をフラッシュメモリ５に退避してからＯＳ８をリセットすると共に、リセット後に重要情報をＲＡＭ４に復帰させるのは第１実施例と同一である。

このような実施例によれば、携帯型読取情報端末１のＯＳ８が起動したときは、優先順位が設定された監視スレッド（１），（２）……を起動して最優先監視スレッドに一定間隔で通知すると共に、最優先監視スレッドにより監視スレッド（１），（２）……からの通知状況を監視するようにしたので、割り込み処理を用いることなくＯＳ８が不安定となったことをユーザに報知することができると共に、ＯＳ８の不安定状態を自動的に解消することができる。

（第３実施例）
次に、上記診断プログラム（ｂ）を説明する第３実施例について図１２及び図１３を参照して説明する。この第３実施例は、メモリリークによる異常に対処するものである。
メモリリークとは、携帯型読取情報端末１の動作中に、使用可能なメモリ容量がだんだん減っていく現象である。ＯＳ８やアプリケーションソフトが処理のために占有したメモリ領域を、なんらかの理由で解放しないまま放置してしまうために起きる。多くの場合、ＯＳ８のメモリ管理方法に問題があったり、アプリケーションソフトに不具合(バグ)が残っていたりすることが原因である。メモリリークにより利用可能なメモリ領域が減少すると、システムの性能が低下したり、不安定になったりする。

ソフトウェア構成を示す図１２において、監視スレッド１１としてロック診断プログラムの機能を有する監視スレッドが設定されている。ＯＳ８は、各スレッドのメモリ使用サイズを提供するＡＰＩ（Application Programming Interface、提供手段に相当）を有している。ロック診断プログラムの機能を有する監視スレッド１１は、図１３に示すように、ＯＳ８に対して各スレッドのメモリ使用サイズを問い合わせ、その応答により各スレッドのメモリ使用サイズを取得する。監視スレッド１１は、各スレッドのメモリ使用サイズが予め決められたメモリサイズを超えた場合、ロック状況に近いと判断する。この場合、予め決められたメモリサイズは、アプリケーション或いはユーザの操作により任意に設定可能となっている。

監視スレッド１１がメモリサイズは予め決められたメモリサイズを超えたと判断したときは、ＲＡＭ４に記憶されている重要情報をフラッシュメモリ５に退避してからＯＳ８をリセットすると共に、リセット後に重要情報をＲＡＭ４に復帰させるのは第１実施例と同一である。

このような実施例によれば、スレッドの異常動作によりメモリ使用サイズが通常よりも大きくなった場合は、ロック状況であると判断し、そのことをユーザに報知すると共にＯＳ６をソフトリセットするようにしたので、ＯＳ８がロックしてしまうことを未然に防止することができる。

尚、ＯＳ８がスレッド全体のメモリ使用サイズを提供するＡＰＩを有し、監視スレッド１１によるロック診断プログラムは、定期的にＯＳ８に対してスレッド全体のメモリ使用サイズを問い合わせ、その応答によりスレッド全体のメモリ使用サイズを取得し、スレッド全体のメモリ使用サイズが予め決められたメモリサイズを越えた場合、ロック状況に近いと判断するようにしてもよい。この場合、予め決められたメモリサイズは、アプリケーション或いはユーザの操作により任意に設定できるのが望ましい。

（第４実施例）
次に、上記診断プログラム（ｃ）を説明する第４実施例について図１４及び図１５を参照して説明する。この第４実施例は、携帯型読取情報端末１が有する必須機能が動作しているかに基づいてＯＳ８を判断することを特徴とする。

ソフトウェア構成を示す図１４において、ユーザスレッド１０またはドライバスレッド９は、それらに組み込まれた必須の機能を実現する必須スレッド（１），（２）……を有すると共に、診断プログラムの機能を備えた割り込み処理１２を有している。

必須スレッド（１），（２）……とは、携帯型読取情報端末１が動作中に必ず必ず動作しなければならない処理であり、キー入力を受け付ける、或いはタップ入力を受け付けるなどである。これらの入力が受け付けられなくなった場合は、何らかの障害でロックしていると推定される。
このような必須スレッド（１），（２）……のロックを検出するために、必須スレッド（１），（２）……は、図１５に示すように、定期的にＲＡＭ４上の動作状況監視フラグをセットする。

診断プログラムを備えた割り込み処理１２は、動作状況監視フラグを定期的に監視（ポーリング）し、予め決められた所定時間内に更新されない動作状況監視フラグがある場合、その動作状況監視フラグを更新する必須スレッド（１），（２）……がロックしたと判断してユーザに報知する。この場合、予め決められた所定時間は、アプリケーションまたはユーザの操作により任意に設定可能となっている。

割り込み処理１２が必須スレッド（１），（２）……はロック状況に近いと判断したときは、ＲＡＭ４に記憶されている重要情報をフラッシュメモリ５に退避してからＯＳ８をリセットすると共に、リセット後に重要情報をＲＡＭ４に復帰させるのは第１実施例と同一である。

このような実施例によれば、診断プログラムを備えた割り込み処理１２は、予め決められた時間内に動作状況を通知しない必須スレッド（１），（２）……があった場合は、当該必須スレッド（１），（２）……がロックしたと判断するようにしたので、携帯型読取情報端末１に必ず設けられている必須スレッド（１），（２）……を利用してロックの監視を行うことができる。

（第５実施例）
次に、上記診断プログラム（ｃ）を説明する第５実施例について図１６及び図１７を参照して説明する。
ソフトウェア構成を示す図１６において、必須スレッド（１），（２）……は、定期的に動作状況を最優先監視スレッドに通知する（図１７参照）。最優先監視スレッドは、必須スレッド（１），（２）……からの動作状況の通知を定期的にチェックし、予め決められた所定時間内に動作状況を通知しない必須スレッド（１），（２）……があった場合、その必須スレッド（１），（２）……がロックしたと判断する。

このような実施例によれば、携帯型読取情報端末１のＯＳ８が起動したときは、必須スレッド（１），（２）……を起動して最優先監視スレッドに一定間隔で通知すると共に、最優先監視スレッドにより必須スレッド（１），（２）……からの通知状況に基づいて各プログラムの動作時間を監視するようにしたので、第４実施例のように割り込み処理を用いることなくＯＳ８が不安定となったことをユーザに報知することができると共に、ＯＳ８の不安定状態を自動的に解消することができる。

（第６実施例）
次に、上記診断プログラム（ｄ）を説明する第６実施例について図１８及び図１９を参照して説明する。この第６実施例は、処理速度に基づいてＯＳ８の異常を判断することを特徴とするものである。

第１実施例と同様に、ＯＳ８は、起動したときは、各優先順位の監視スレッド（１），（２）……を一定間隔で起動し、決められたプログラムを動作させ、その動作時間を測定する。この結果をＲＡＭ４の動作時間結果エリアに保存し、診断プログラムを備えた割り込み処理１２でこれらの動作時間を確認し、処理が遅くなっているかどうかを判断する（図１９参照）。この判断としては、各優先順位の処理について、予め決められた所定時間よりも長くかかっているかを判断する。

このような実施例によれば、プログラムの実行時間に基づいてロックしているかを判断するようにしたので、ロックするのに先立って対処することが可能となり、早い段階でＯＳ８の不安定状態に対処することができる。

（第７実施例）
次に、上記診断プログラム（ｄ）を説明する第７実施例について図２０及び図２１を参照して説明する。この第７実施例は、最優先監視スレッドによりプログラムの実行時間を監視することを特徴とする。

ソフトウェア構成を示す図２０において、監視スレッド（１），（２）……は、一定間隔毎に動作時間を最優先監視スレッドに通知し、最優先監視スレッドは、監視スレッド（１），（２）……から通知された動作時間に基づいてプログラムの実行時間の遅れを監視するようになっている。

このような実施例によれば、携帯型読取情報端末１のＯＳ８が起動したときは、優先順位が設定された監視スレッド（１），（２）……を起動して最優先監視スレッドに一定間隔で通知すると共に、最優先監視スレッドにより監視スレッド（１），（２）……からの通知状況に基づいてプログラムの実行時間を監視するようにしたので、割り込み処理を用いることなくＯＳ８が不安定となったことをユーザに報知することができると共に、ＯＳ８の不安定状態を自動的に解消することができる。

（第８実施例）
次に、本発明の第８実施例について図２２を参照して説明する。この実施例は、携帯型読取情報端末１がアプリケーションをＷｅｂサーバからダウンロードしながら実行する構成に適用したものである。

図２２は、携帯型読取情報端末１とＷｅｂサーバ２１を概略的に示している。Ｗｅｂサーバ２１には携帯型読取情報端末１の業務アプリケーションとして例えば棚卸しアプリケーション（URL:/tanaoroshi/html）、在庫確認アプリケーション1/5（URL:/zaiko.html）、在庫確認アプリケーション2/5（URL:/zaiko.html）、……が登録されていると共に、通信デバイス２２を備えて構成されている。

携帯型読取情報端末１はＷｅｂブラウザ２３及び通信デバイス２４を備えて構成されており、通信デバイス２４をインターネット２５に接続した状態でＷｅｂブラウザを起動することにより通信デバイス２４を通じてＷｅｂサーバ２１にアクセスし、Ｗｅｂサーバ２１に登録されている所定の業務プログラムをダウンロードして実行するようになっている。

ここで、携帯型読取情報端末１は、業務プログラムをダウンロードする際は、そのＵＲＬをフラッシュメモリ５に一時記憶するようになっている。
ユーザは携帯型読取情報端末１により作業を実行する場合は、携帯型読取情報端末１からＷｅｂサーバ２１にアクセスし、Ｗｅｂサーバ２１からユーザが所望する業務プログラムをダウンロードして実行する。業務プログラムが図２２に示す在庫確認プログラムのように分割されている場合は、在庫確認プログラムを携帯型読取情報端末１に順にダウンロードしながら実行するようになっている。

さて、携帯型読取情報端末１に業務プログラムをダウンロードして作業する場合は、フラッシュメモリ５にはダウンロードしている業務プログラムのＵＲＬが一時記憶されていることになる。例えば在庫確認アプリケーションをダウンロードしながら在庫確認作業を実行する場合は、フラッシュメモリ５にはアプリケーションの動作位置として在庫確認アプリケーションのうち現在ダウンロードしているＵＲＬが一時記憶されている。

携帯型読取情報端末１により在庫確認作業中に、上記各実施例で説明した診断プログラムによりＯＳ８がロックしたと判断した場合は、ＲＡＭ４のデータをフラッシュメモリ５に退避してからＯＳ８に対してリセット要求を指令する。これにより、ＯＳ８が再起動するようようなる。このとき、フラッシュメモリ５には動作位置を示すＵＲＬが記憶されていると共に、在庫確認作業中に入力したデータが一時記憶されているので、ＯＳ８は、動作位置を示すＵＲＬに基づいてＷｅｂサーバ２１から中断した在庫確認アプリケーションを再びダウンロードして実行するようになると共に、フラッシュメモリ５に退避していたデータをＲＡＭ４に復帰するようになる。従って、ユーザは、特別な操作を行うことなく中断した棚卸し作業を再開することができる。

このような実施例によれば、携帯型読取情報端末１にサーバから業務プログラムをダウンロードしながら実行する構成において、ダウンロードした業務プログラムの動作位置をフラッシュメモリ５に一時記憶すると共に、ＯＳ８がロックしたと判断したときは、業務プログラムの実行中における入力データをフラッシュメモリ５に一時記憶するようにしたので、業務プログラムの実行中に携帯型読取情報端末１のＯＳ８がロックした場合であっても、中断した業務プログラムを再開することができる。従って、携帯型読取情報端末１による業務プログラムの作業中にＯＳ８がロックした場合であっても、ユーザは面倒な作業を行うことなく業務プログラムを再開することができるので、使い勝手に優れている。

本発明は、上記実施例に限定されることなく、例えば携帯型読取情報端末以外の各種携帯端末に適用してもよいなど、要旨を逸脱しない範囲で変形または拡張できる。

本発明の実施例を説明するための携帯型読取情報端末のハードウェア及びソフトウェアの構造を示す図 本発明の第１実施例を示すソフトウェアの構成を示す図 監視スレッドと動作状況監視フラグとの関係を示す図 監視スレッドの動作を示すフローチャート 割り込み処理による診断プログラムの動作を示すフローチャート ロック警告の表示動作を示す図２相当図 ハードウェア構成を示す図 ソフトウェア構成及びハードウェア構成を示す図 図８相当図 本発明の第２実施例を示す図２相当図 図３相当図 本発明の第３実施例を示す図２相当図 監視スレッドの動作を説明するための図 本発明の第４実施例を示す図２相当図 図３相当図 本発明の第５実施例を示す図２相当図 図３相当図 本発明の第６実施例を示す図２相当図 図３相当図 本発明の第７実施例を示す図２相当図 図３相当図 本発明の第８実施例を説明するためのハードウェア及びソフトウェアを示す図

符号の説明

図面中、１は携帯型読取情報端末（携帯端末）、５はフラッシュメモリ、８はオペレーティングシステム、１０はＯＳ（提供手段に相当）、１１は監視スレッド（予測手段、回避策実行手段）、１２は割り込み処理（予測手段、回避策実行手段）である。

Claims (18)

1. オペレーティングシステムによりアプリケーション及びドライバなどの動作を管理する携帯端末において、
   以下の何れかの診断内容（ａ）〜（ｄ）を診断し、その診断結果に基づいて前記オペレーティングシステムが不安定状態となったことを予測する予測手段と、
   （ａ）前記オペレーティングシステムが割当てる処理の優先レベル毎に停止しているかどうかを診断
   （ｂ）アプリケーションやドライバなどが確保しているメモリサイズを定期的に診断
   （ｃ）携帯端末に搭載されている必須機能が動作しているかを診断
   （ｄ）前記オペレーティングシステムが割当てる処理の優先レベル毎に処理速度を診断
   前記予測手段が前記オペレーティングシステムは不安定状態となったと予測した場合は、予測された不安定状態に応じた所定の回避策を実行する回避策実行手段とを備えたことを特徴とする携帯端末。
2. 前記診断内容（ａ）を診断する前記予測手段は、異なる優先順位が設定された複数の監視スレッドと、割り込み処理する診断プログラムとから構成され、
   前記監視スレッドは、自己に対応する動作状況監視フラグを定期的にセットし、
   前記診断プログラムは、前記動作状況監視フラグを割り込み処理により定期的に監視し、所定時間内に更新されない前記動作状況監視フラグがある場合は、当該動作状況監視フラグを更新する監視スレッドより優先順位が同一または上位のスレッドが不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
3. 前記診断内容（ａ）を診断する前記予測手段は、異なる優先順位が設定された複数の監視スレッドと、これらの監視スレッドを監視する最優先監視スレッドとから構成され、
   前記監視スレッドは、動作状況を前記最優先監視スレッドに定期的に通知し、
   前記最優先監視スレッドは、前記監視スレッドからの動作状況の通知を定期的にチェックし、所定時間内に動作状況を通知しない前記監視スレッドがあった場合は、当該監視スレッドより優先順位が同一または上位のスレッドが不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
4. 複数の監視スレッドの優先順位は、アプリケーションまたはドライバなどの各スレッドに設定された優先順位と同一または優先順位間となるように設定されていることを特徴とする請求項２または３記載の携帯端末。
5. 前記所定時間は、アプリケーションまたはユーザの操作により設定可能であることを特徴とする請求項２ないし４の何れかに記載の携帯端末。
6. 前記診断内容（ｂ）を診断する前記予測手段は、監視スレッドと、アプリケーションまたはドライバなどの各スレッドのメモリ使用サイズを提供する提供手段とから構成され、
   前記監視スレッドは、前記提供手段に対して各スレッドのメモリ使用サイズを定期的に問合せ、その応答により各スレッドのメモリ使用サイズを取得し、当該メモリ使用サイズが所定メモリサイズを越えた場合は、不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
7. 前記診断内容（ｂ）を診断する前記予測手段は、監視スレッドと、スレッド全体のメモリ使用サイズを提供する提供手段とから構成され、
   前記監視スレッドは、前記提供手段に対してスレッド全体のメモリ使用サイズを定期的に問合せ、その応答によりスレッド全体のメモリ使用サイズを取得し、当該メモリ使用サイズが所定メモリサイズを越えた場合は、不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
8. 前記所定メモリサイズは、アプリケーションまたはユーザの操作により設定可能であることを特徴とする請求項６または７記載の携帯端末。
9. 前記診断内容（ｃ）を診断する前記予測手段は、前記必須機能を実現する必須スレッドと、割り込み処理する診断プログラムとから構成され、
   前記必須スレッドは、自己に対応する動作状況監視フラグを定期的にセットし、
   前記診断プログラムは、前記動作状況監視フラグを割り込み処理により定期的に監視し、所定時間内に更新されない動作状況監視フラグがある場合は、当該動作状況監視フラグを更新する必須スレッドが不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
10. 前記診断内容（ｃ）を診断する前記予測手段は、前記必須機能を実現する必須スレッドと、この必須スレッドを監視する監視スレッドとから構成され、
    前記必須スレッドは、動作状況を前記監視スレッドに定期的に通知し、
    前記監視スレッドは、前記必須スレッドからの動作状況の通知を定期的にチェックし、所定時間内に動作状況を通知しない必須スレッドがあった場合は、当該必須スレッドが不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
11. 前記所定時間は、アプリケーションまたはユーザの操作により設定可能であることを特徴とする請求項９または１０記載の携帯端末。
12. 前記診断内容（ｄ）を診断する前記予測手段は、自己に対応する検査用プログラムを実行する複数の監視スレッドと、割り込み処理する診断プログラムとから構成され、
    前記監視スレッドは、検査用プログラムを定期的に動作させ、その検査用プログラムの開始から終了までに要した時間を動作時間結果エリアに格納し、
    前記診断プログラムは、前記動作時間結果エリアを割り込み処理により定期的に監視し、前記検査用プログラムの開始から終了までに要した時間に基づいて動作速度を求め、当該動作速度が所定速度より遅い場合は、不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
13. 前記診断内容（ｄ）を診断する前記予測手段は、異なる優先順位が設定された複数の監視スレッドと、これらの監視スレッドを監視する最優先監視スレッドとから構成され、
    前記監視スレッドは、検査用プログラムを定期的に動作させ、その検査用プログラムの開始から終了までに要した時間を前記最優先監視スレッドに通知し、
    前記最優先監視スレッドは、前記監視スレッドからの時間通知を定期的にチェックし、前記検査用プログラムの開始から終了までに要した時間に基づいて動作速度を求め、当該動作速度が所定速度より遅い場合は、不安定状態となったと判断することを特徴とする請求項１記載の携帯端末。
14. 前記所定速度は、アプリケーションまたはユーザの操作により設定可能であることを特徴とする請求項１２または１３記載の携帯端末。
15. 前記予測手段が不安定状態となったと判断したときは、そのことをユーザに報知する報知手段を備えたことを特徴とする請求項１ないし１４の何れかに記載の携帯端末。
16. 前記回避策実行手段は、前記予測手段が不安定状態となったと判断したときは、前記オペレーティングシステムに対してリセット要求を指令することを特徴とする請求項１ないし１５の何れかに記載の携帯端末。
17. 前記回避策実行手段は、前記予測手段が不安定状態となったと判断したときは、前記オペレーティングシステムにリセット要求を指令するのに先立って、所定データを退避させることを特徴とする請求項１６記載の携帯端末。
18. 前記所定データは、アプリケーションまたはユーザの操作により設定可能であることを特徴とする請求項１７記載の携帯端末。

Images