(57)【要約】【課題】通常時のログ出力は抑えながら、アプリケーションに異常が発生する前にログレベルを上げることにより、原因追究に必要なログ出力を得ることを可能とすること。【解決手段】状態検出部４０において検出された状態から、システム状態判定手段３６４がシステムの状態を判定する。そして、判定されたシステムの状態に基づいて、ログ出力基準書換手段３６６により、ログ出力基準データ３４４が書き換えられる。これにより、アプリケーション・プログラム３４は、現在のシステムの状態に適したログレベルのログをログ出力部１８から出力することができる。【選択図】図１
2009110156.tif 000002
【特許請求の範囲】
【請求項１】
ログレベルが定められたログ出力命令を含むアプリケーション・プログラムをシステム上で実行することにより、ログを出力するログ出力手段を備えたログ出力装置において、
前記ログ出力手段が出力対象とするログの基準レベルであるログ出力基準データを記憶するログ出力基準データ記憶手段と、
前記システムの状態を判断するための情報を検出する状態検出手段と、
前記状態検出手段により検出されたシステムの状態に応じて、前記ログ出力基準データを書き換えるログ出力基準データ書換手段と、
を備え、
前記ログ出力手段は、前記ログ出力命令ごとに定められたログレベルと、ログ出力基準データとを比較し、ログレベルがログ出力基準データ以下である場合にログ出力を行うことを特徴とするログ出力装置。
【請求項２】
前記システムの状態を判定するための条件を記憶する判定条件テーブルを更に有し、
前記ログ出力基準データ書換手段は、前記状態検出手段により検出された情報から、前記判定条件テーブルに基づいてログ出力基準データを書き換える手段であることを特徴とする請求項１に記載のログ出力装置。
【請求項３】
前記状態検出手段は、前記システムの状態を判断するための情報として、システムの状態が異常であることを検出する手段であり、
前記ログ出力基準データ書換手段は、前記状態検出手段により、システムの状態が異常であると検出された場合には、ログ出力基準データを上げることを特徴とする請求項１に記載のログ出力装置。
【請求項４】
コンピュータ上で、ログレベルが定められたログ出力命令を含むアプリケーション・プログラムが実行されることにより、ログを出力するログ出力機能を含むログ出力プログラムにおいて、
前記ログ出力機能が出力対象とするログの基準レベルであるログ出力基準データと、
前記システムの状態を判断するための情報を検出する状態検出機能と、
前記状態検出機能により検出されたコンピュータの状態に応じて、前記ログ出力基準データを書き換えるログ出力基準データ書換機能と、
を備え、
前記ログ出力機能は、前記ログ出力命令ごとに定められたログレベルと、ログ出力基準データとを比較し、ログレベルがログ出力基準データ以下である場合にログ出力を行うことを特徴とするログ出力プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ログレベルが定められたログ出力命令を含むアプリケーション・プログラムをシステム上で実行することにより、ログを出力するログ出力手段を備えたログ出力装置等に関する。
【背景技術】
【０００２】
コンピュータ上で実行されるアプリケーション・プログラムにおいて、実行状態を記録するログ出力装置が知られている。ログ出力装置において取得されたログは、プログラムの正常実行を妨げる原因が発生していないか、あるいはプログラムが意図したとおりに動作しているか否か等を調べるために用いることができる。したがって、アプリケーションにトラブルが発生した場合に、その原因を究明することや、アプリケーション開発中の動作確認を行うこと等が可能となる。
【０００３】
当該ログは、一般的にはアプリケーション・プログラムの要所に書き込んだログ出力命令により、ログファイルやコンソール上に出力されるようになっている。通常ログ出力命令にはその出力内容の重要度を示す指標であるログレベルが定められている。例えば、プログラムの開発、デバッグ時は不具合検出のために全てのログレベルのログ出力命令に対して実際にログを出力させて開発の効率化に役立てられている。
【０００４】
しかし、プログラム自体が大きい場合、全てのログを出力させるとその量は膨大になってしまう。すると、ログの出力に時間を要することにより、アプリケーションの処理速度が低下してしまう問題がある。そこで、重要なログレベルのログのみを出力させて、ログレベルがプログラム内で定義された基準以下であるログのみを出力させ、処理速度の低下とログの肥大化の防止が行われる。ログ出力を制限するためにどのログレベルから実際にログの出力を行わせるかの出力基準をログ出力基準と呼ぶこととする。
【０００５】
ここで、具体的に、従来のログの出力方法について、ＬｉｎｕｘをＯＳとするテレビ受像機を例にとって説明する。図１８は、テレビ受像機９における構成図である。図１８に示すように、テレビ受像機９は、ＣＰＵ１０に、チューナ部１２と、デコード部１４と、記憶部１６と、ログ出力部１８と、表示部２０と、音声出力部２２と、ＨＤＤ３０とがバスを介して接続されている。また、放送波を受信するためのアンテナＡＮＴがチューナ部１２に接続されている。
【０００６】
ＣＰＵ１０は、カーネル・プログラムとアプリケーション・プログラムをマルチタスクとして並行に実行し、その実行命令に従ってメモリ装置にアクセスしたり、ログ出力手段に出力データを送ったり、その他テレビシステム全体の制御を行っている。
【０００７】
チューナ部１２は、アンテナＡＮＴから受信された放送信号から、所望する番組の映像信号及び音声信号を抽出する機能部である。チューナ部１２において抽出された映像信号及び音声信号は、デコード部１４に出力される。
【０００８】
デコード部１４は、チューナ部１２より出力された映像信号及び音声信号をデコード（復調）する機能部である。デコードされた映像信号は表示部２０に、音声信号は音声出力部２２に出力される。
【０００９】
記憶部１６は、各種プログラムが実行されるときに、作業用として利用するメモリ領域である。例えば、ＨＤＤ３０に記憶されているプログラムは、一度記憶部１６に展開され、ＣＰＵ１０により実行される。ここで、記憶部１６は、例えばＤＲＡＭ等の各種メモリ素子で構成されている。
【００１０】
ログ出力部１８は、アプリケーション・プログラム３４により受け取った出力データのコンソール上またはログファイルへの出力を行う機能部である。
【００１１】
表示部２０は、デコード部１４から出力された映像信号を表示する為の機能部である。また、音声出力部２２は、デコード部１４から出力された音声信号を出力するための機能部である。ここで、一例として表示部２０はＬＣＤにより、音声出力部２２は、スピーカにより構成されている。
【００１２】
ＨＤＤ３０は、テレビ受像機において、各種プログラムや、データなどを保持する外部記憶装置である。なお、図１のテレビ受像機９においては、Ｌｉｎｕｘカーネル３２と、アプリケーション・プログラム３４とが格納されている。また、ここでは外部記憶装置の一例としてＨＤＤを例にとって説明しているが、フラッシュメモリ等の他の記憶装置でも良いことは勿論である。
【００１３】
Ｌｉｎｕｘカーネル３２は、タスクの管理を行う特別なプログラムであり、アプリケーション・プログラム３４における複数のタスクの切り替えを行い、複数のタスクを平行に実行できるように制御する機能を有している。
【００１４】
アプリケーション・プログラム３４では、複数の機能を有したタスクが実行され、アンテナＡＮＴにより受信した放送波からチューナ部１２で映像信号、音声信号を抜き出し、映像信号及び音声信号をデコード部１４でデコードを行った後に、表示部２０に映像信号を、音声出力部２２に音声信号の出力を行うためのプログラムである。
【００１５】
また、アプリケーション・プログラム３４は、プログラム中に含まれるログ出力命令を実行し、ログを出力させる動作が実行される。これはアプリケーション・プログラム実行中、バグ等のために意図しない異常動作をすることがあり、プログラム開発の際、バグの原因追及、プログラムの動作確認等デバッグ作業支援のためである。また、アプリケーション・プログラム３４には、ログ出力命令レベルテーブル３４２と、ログ出力基準データ３４４とが含まれている。
【００１６】
ログ出力命令レベルテーブル３４２は、ログの出力の対象となる命令（ログ出力命令）と、当該ログ出力命令のログレベルとを対応づけて記憶しているテーブルである。ここで、ログ出力命令レベルテーブル３４２の一例を図１９に示す。図１９に示すように、ログ出力命令（例えば、「free」）と、ログレベル（例えば、「１」）とが対応づけられて記憶されている。
【００１７】
ログ出力基準データ３４４は、アプリケーション・プログラム３４におけるログ出力基準が記憶されている。ここで、ログ出力基準とは、ログ出力命令の実行時に、どのログレベルからログ出力を実際に行うかを決めたしきい値であり、アプリケーション・プログラム３４毎に定められた値である。
【００１８】
具体的に、ログ出力命令によりログ出力が行われる仕組みについて、図２０に示す動作フローを用いて説明する。
【００１９】
まず、ステップＳ９０においてログ出力命令のログレベルを、ログ出力命令レベルテーブル３４２から読み出す。続いて、ステップＳ９２において、読み出されたログレベルと、ログ出力基準データ３４４とを比較する。ここで、ログレベル≦ログ出力基準データ３４４であれば（ステップＳ９２；Ｙｅｓ）、ログ出力部１８を介してログを出力する（ステップＳ９４）。他方、ログレベル＞ログ出力基準データ３４４であれば（ステップＳ９２；Ｎｏ）、ログを出力せずそのまま終了する。
【００２０】
ここで、ログが出力される動作例について説明する。例えば、ログ出力の簡単な例として、命令を実行することによりエラーが起こった場合を「ログレベル０」、命令が実行出来た場合を「ログレベル１」で知らせるログ出力命令を持ったサンプルプログラムを実行した例を図２１に示す。
【００２１】
図２１（ａ）は、ログ出力基準を「０」として実行した場合のログ出力であり、図２１（ｂ）は、ログ出力基準を「１」で実行した場合のログ出力の最後部分である。ログ出力基準「０」では、エラーが発生した事実しかわからないが、ログ出力基準を「１」として設定していると、出力されるログは多くなるが、エラー発生前のコマンドも記録に残っているため原因の追究をすることが可能となる。
【００２２】
しかし、この方法ではアプリケーションにトラブルが発生した際に得られるログ情報量が適切ではなく、トラブルの原因究明が困難になってしまうという問題が生じる。
【００２３】
アプリケーションにトラブルが発生した場合には、その原因の究明を適切かつ迅速に行うために、そのトラブルに関してなるべく多くのログ情報が必要である。
【００２４】
この問題を解決する方法として、例えば、特許文献１に記載の方法がある。特許文献１の方法は、アプリケーションにトラブルが発生したことを、完全停止に至る前に検出し、トラブル発生を検出した際にアプリケーションのログ出力基準を自動変更することにより、通常時のログ出力量を少なく保ちながら、トラブル発生時には十分なログを得ることを可能としたものである。
【特許文献１】特開平１１−３２７９６５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２５】
しかし、特許文献１の方法ではアプリケーションに異常が発生した後にログ出力基準の変更が行われるため、トラブル発生に至るまではログ出力基準が低い状態のままであり、結果として異常発生の原因追求に必要なログを十分に取ることができないという問題があった。
【００２６】
そこで、本発明の目的は、通常時のログ出力は抑えながら、アプリケーションに異常が発生する前にログレベルを上げることにより、原因追究に必要なログ出力を得ることを可能とすることを目的とする。
【課題を解決するための手段】
【００２７】
上述した課題に鑑み、本発明は、ログレベルが定められたログ出力命令を含むアプリケーション・プログラムをシステム上で実行することにより、ログを出力するログ出力手段を備えたログ出力装置において、前記ログ出力手段が出力対象とするログの基準レベルであるログ出力基準データを記憶するログ出力基準データ記憶手段と、前記システムの状態を判断するための情報を検出する状態検出手段と、前記状態検出手段により検出されたシステムの状態に応じて、前記ログ出力基準データを書き換えるログ出力基準データ書換手段と、を備え、前記ログ出力手段は、前記ログ出力命令ごとに定められたログレベルと、ログ出力基準データとを比較し、ログレベルがログ出力基準データ以下である場合にログ出力を行うことを特徴とする。
【００２８】
また、本発明は、前記システムの状態を判定するための条件を記憶する判定条件テーブルを更に有し、前記ログ出力基準データ書換手段は、前記状態検出手段により検出された情報から、前記判定条件テーブルに基づいてログ出力基準データを書き換える手段であることを特徴とする。
【００２９】
また、本発明は、前記状態検出手段は、前記システムの状態を判断するための情報として、システムの状態が異常であることを検出する手段であり、前記ログ出力基準データ書換手段は、前記状態検出手段により、システムの状態が異常であると検出された場合には、ログ出力基準データを上げることを特徴とする。
【００３０】
また、本発明は、コンピュータ上で、ログレベルが定められたログ出力命令を含むアプリケーション・プログラムが実行されることにより、ログを出力するログ出力機能を含むログ出力プログラムにおいて、前記ログ出力機能が出力対象とするログの基準レベルであるログ出力基準データと、前記システムの状態を判断するための情報を検出する状態検出機能と、前記状態検出機能により検出されたコンピュータの状態に応じて、前記ログ出力基準データを書き換えるログ出力基準データ書換機能と、を備え、前記ログ出力機能は、前記ログ出力命令ごとに定められたログレベルと、ログ出力基準データとを比較し、ログレベルがログ出力基準データ以下である場合にログ出力を行うことを特徴とする。
【発明の効果】
【００３１】
本発明によれば、システムの状態に応じて、ログ出力基準データが書換えられることとなり、ログ出力命令ごとに定められたログレベルと、当該ログ出力基準データとを比較し、ログレベルがログ出力基準データ以下である場合にログ出力を行うこととなる。
【００３２】
したがって、システムの状態に応じてログ出力基準データが書き換わることにより、例えばシステムの状態が正常時と、異常時で異なるログレベルのログが出力されることとなり、より適切なログを取得することが可能となる。
【発明を実施するための最良の形態】
【００３３】
続いて、本発明におけるログ出力装置を適用した実施形態として、ＬｉｎｕｘをＯＳとして採用したテレビ受像機を例にとって説明する。図１は、本実施形態におけるテレビ受像機１における構成図である。図１に示すように、テレビ受像機１は、ＣＰＵ１０に、チューナ部１２と、デコード部１４と、記憶部１６と、ログ出力部１８と、表示部２０と、音声出力部２２と、ＨＤＤ３５と、状態検出部４０とがバスを介して接続されている。また、放送波を受信するためのアンテナＡＮＴがチューナ部１２に接続されている。
【００３４】
なお、図１に示すテレビ受像機１と、図１８において説明した従来のテレビ受像機９と同一の構成要素については同一の符号を付すことにより詳細な説明を省略する。
【００３５】
状態検出部４０は、テレビ受像機１において、アプリケーション・プログラム３４が実行された場合における各種状態を検出する機能部である。ここで、状態検出部４０が検出する状態は後述するが、例えば、メモリ空き容量や、温度等である。
【００３６】
また、ＨＤＤ３５にはＬｉｎｕｘカーネル３２と、アプリケーション・プログラム３４と、異常検出プログラム３６とが格納されている。また、異常検出プログラム３６には、判定条件テーブル３６２と、システム状態判定手段３６４と、ログ出力基準書換手段３６６とが含まれている。
【００３７】
判定条件テーブル３６２は、状態検出部４０において、検出される状態値に基づいてシステムを正常であるか、異常であるか等を判定するための条件を記憶しているテーブルである。判定条件テーブル３６２には、判定パラメータと、条件と、システム状態とが対応づけて記憶されている。
【００３８】
システム状態判定手段３６４は、状態検出部４０において検出される状態値に基づいてテレビ受像機１のシステムの状態が正常であるか、異常であるか等を判定する手段である。判定条件テーブル３６２に記憶されている判定パラメータ及び条件を利用することにより、システムの状態を判定する。
【００３９】
ログ出力基準書換手段３６６は、ログ出力基準データ３４４を書き換える手段である。システム状態判定手段３６４によってシステムの状態（アプリケーション・プログラム３４の状態）に応じて実行され、アプリケーション・プログラム３４に定められているログ出力基準データ３４４を変更する処理を行う。
【００４０】
異常検出プログラム３６において実行される異常検出処理を図２を用いて説明する。まず、ステップＳ１０において、プロセスの開始時の前処理が実行される。具体的には、判定条件テーブル３６２に基づいて、状態検出部４０から検出する状態値を特定する作業や、判定パラメータを読み出す処理を実行する。
【００４１】
つづいて、ステップＳ１２において、状態検出部４０からアプリケーション・プログラム３４が実行されている場合における所定の状態値を検出する。ここで、検出される間隔は、例えば所定時間毎に検出されたり、イベント発生時に検出されたりするなど、いずれのタイミングであっても良い。また、検出される状態値としては、例えばメモリエリアの空き容量であったり、ＣＰＵの稼働率であったり、システムの温度であったり、システムの状態が解るいずれかの値である。どの値を状態値として検出するかは、判定条件テーブル３６２に基づいて決定される。
【００４２】
続いて、ステップＳ１４において、システム状態判定手段３６４を用いることにより、現在のシステムの状態が「正常」であるか「異常」であるかを判定する。ここで、判定される状態としては「正常」と「異常」と判定しても良いし、複数のレベルに判定しても良い。
【００４３】
そして、ステップＳ１６において、ステップＳ１４において判定されたシステムの状態に基づいてログ出力基準データ３４４を更新する。そして、ステップＳ１２に処理が戻ることにより、アプリケーション・プログラム３４が実行されている間、並行して状態検出部４０により状態値が検出され、当該状態値に応じてログ出力基準データ３４４が更新されることとなる。
【００４４】
したがって、アプリケーション・プログラム３４が実行されている間にログが出力されている場合（図２０のステップＳ９４）、システムの状態に応じたログレベルのログ命令が出力されることとなる。
【００４５】
それでは、上述した異常検出プログラムを動作を具体的に以下の各実施例において説明する。
【００４６】
〔第１実施例〕
まず、第１実施例として、異常検出を行うための判定パラメータとして、物理メモリ装置における未使用の領域（メモリフリーエリア）の大きさを利用する場合について説明する。
【００４７】
本実施例において、状態検出部４０は、メモリフリーエリアの大きさを取得する。具体的には、ＬｉｎｕｘをＯＳとする場合、／ｐｒｏｃ／ｍｅｍｉｎｆｏからＭｅｍＦｒｅｅの値の読み出すことによりソフト上で値を取得することができる。
【００４８】
また、異常検出プログラム３６は、状態検出部４０から状態値として、メモリフリーエリアの大きさを定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００４９】
また、第１実施例における判定条件テーブル３６２の一例を図３に示す。図３に示すように、判定パラメータとして「メモリフリーエリア」が設定されている。ここで、本実施例ではプログラムの設計上メモリフリーエリアの大きさが「１Ｍｂｙｔｅ」より小さくなることはないとする。このとき、条件としてメモリフリーエリアが「１Ｍｂｙｔｅ以上」の場合はシステム状態が「正常」であると判定され、「１Ｍｂｙｔｅ未満」の場合はシステム状態が「異常」であると判定される。
【００５０】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００５１】
つづいて、ステップＳ１２により、状態検出部４０からメモリフリーエリアの大きさを状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（メモリフリーエリア）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、メモリフリーエリアの大きさが「１Ｍｂｙｔｅ未満」であれば異常状態としてログ出力基準データ３４４の値を「１」に、「１Ｍｂｙｔｅ以上」であれば正常状態としてログ出力基準データ３４４の値を「０」とする。
【００５２】
図４は、メモリの状態を模式的に示した図である。図４（ａ）は、メモリフリーエリアが「１Ｍｂｙｔｅ未満」である。この場合は、ログ出力基準は「１」となる。また、図４（ｂ）に示すように、メモリフリーエリアが「１Ｍｂｙｔｅ以上」ある場合は、ログ出力は「０」となる。
【００５３】
そして、ステップＳ１６において、ステップＳ１４において判定されたログ出力基準に基づきログ出力基準書換手段３６６は、ログ出力基準データ３４４を書き換える。そして、ステップＳ１２から処理を繰り返し実行する。
【００５４】
このように、本実施例の処理を繰り返し実行することにより、メモリフリーエリアの大きさに応じて正常時と、異常時とが判断され、適宜ログ出力基準データ３４４が変更されることにより、より適切なログが出力されることとなる。特に、プログラム実行中に使用可能なメモリ領域が減少し続けると、システムダウンの危険性が高まることが知られている。したがって、メモリフリーエリアの状態を検出し、当該検出された状態に応じてログ出力基準を変更することにより、適切にログを出力することができるようになる。
【００５５】
なお、検出された状態値によって段階的にログ出力基準データ３４４を変更するように定めておくことも可能である。例えば図５（ａ）、図５（ｂ）ではメモリフリーエリアの大きさに対してしきい値を定めてログ出力基準が「０」から「３」の４段階に設定されている。メモリフリーエリアの大きさが図５（ａ）のような状態である場合はログ出力基準を「３」、図６（ｂ）のような状態である場合はログ出力基準を「１」となるようステップＳ１４でログ出力基準データ３４４の決定を行う。
【００５６】
〔第２実施例〕
次に、第２実施例として、異常検出を行うための判定パラメータとして、ＣＰＵの使用率を利用する場合について説明する。
【００５７】
本実施例において、状態検出部４０は、ＣＰＵ１０の使用率を検出する。具体的には、ＯＳがＬｉｎｕｘである場合、／ｐｒｏｃ／ｓｔａｔからユーザモード、カーネルモード、システムアイドルのＣＰＵ使用時間を読み出すことができ、これらよりＣＰＵ使用率を計算する方法を用いる。
【００５８】
また、異常検出プログラム３６は、状態検出部４０から状態値として、ＣＰＵ１０の使用率を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００５９】
また、第２実施例における判定条件テーブル３６２の一例を図６に示す。図６に示すように、判定パラメータとして「ＣＰＵ使用率」が設定されている。ここで、本実施例では設計上ＣＰＵ使用率が「９５％以上」にはならないこととなっている。このとき、条件としてＣＰＵ使用率が「９５％未満」の場合はシステム状態が「正常」であると判定され、「９５％以上」の場合はシステム状態が「異常」であると判定される。
【００６０】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００６１】
つづいて、ステップＳ１２により、状態検出部４０からＣＰＵの使用率を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（ＣＰＵ使用率）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、ＣＰＵ使用率が「９５％以上」であれば異常状態としてログ出力基準データ３４４の値を「１」に、「９５％未満」である場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００６２】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、ＣＰＵの使用率が「９５％以上」のときはログ出力レベル「２」、「９０％以上９５％未満」のときはログ出力レベル「１」、「９０％未満」のときはログ出力レベル「０」となるよう設定しても良い。
【００６３】
〔第３実施例〕
次に、第３実施例として、異常検出を行うための判定パラメータとして、システムがハードディスクのような補助記憶装置を備えている場合、補助記憶装置の使用量を利用する場合について説明する。
【００６４】
本実施例において、状態検出部４０は、補助記憶装置の使用量を検出する。具体的には、ＯＳがＬｉｎｕｘである場合、ｄｆコマンドを実行することにより取得することが出来るため、これらより補助記憶装置の使用量を計算する方法を用いる。
【００６５】
また、異常検出プログラム３６は、状態検出部４０から状態値として、補助記憶装置の使用量を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００６６】
また、第３実施例における判定条件テーブル３６２の一例を図７に示す。図７に示すように、判定パラメータとして「補助記憶装置の使用量」が設定されている。ここで、本実施例では設計上補助記憶装置の使用量が「１０Ｍｂｙｔｅ以上」とはならないことになっている。このとき、条件として補助記憶装置の使用量が「１０Ｍｂｙｔｅ未満」の場合はシステム状態が「正常」であると判定され、「１０Ｍｂｙｔｅ以上」の場合はシステム状態が「異常」であると判定される。
【００６７】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００６８】
つづいて、ステップＳ１２により、状態検出部４０から補助記憶装置の使用量を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（補助記憶装置の使用量）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、補助記憶装置の使用量が「１０Ｍｂｙｔｅ以上」であれば異常状態としてログ出力基準データ３４４の値を「１」に、「１０Ｍｂｙｔｅ未満」である場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００６９】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、補助記憶装置の使用量が「１０Ｍｂｙｔｅ以上」のときはログ出力レベル「２」、「９Ｍｂｙｔｅ以上１０Ｍｂｙｔｅ未満」のときはログ出力レベル「１」、「９Ｍｂｙｔｅ未満」のときはログ出力レベル「０」となるよう設定しても良い。
【００７０】
〔第４実施例〕
次に、第４実施例として、異常検出を行うための判定パラメータとして、コンピュータ内部（ＣＰＵ）の温度を取得する手段を備えている場合において、ＣＰＵ１０の温度を利用する場合について説明する。
【００７１】
本実施例において、状態検出部４０は、ＡＣＰＩ（Advanced Configuration and Power Interface）によりＣＰＵ１０の温度を検出する。具体的には、ＯＳがＬｉｎｕｘである場合、／ｐｒｏｃ／ａｃｐｉ／ｔｈｅｒｍａｌ＿ｚｏｎｅ／ＴＨＲＭ／ｔｅｍｐｅｒａｔｕｒｅにＡＣＰＩが取得したＣＰＵ１０の温度値を表示されているので、これにより、ＣＰＵ１０の温度を検出する。
【００７２】
また、異常検出プログラム３６は、状態検出部４０から状態値として、ＣＰＵ１０の温度を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００７３】
また、第４実施例における判定条件テーブル３６２の一例を図８に示す。図８に示すように、判定パラメータとして「ＣＰＵの温度」が設定されている。ここで、本実施例ではシステムの設計上、ＣＰＵ１０の温度が通常「６０℃を超える」ことにはならないとする。このとき、条件としてＣＰＵ１０の温度が「６０℃以下」の場合はシステム状態が「正常」であると判定され、「６０℃を超える」場合はシステム状態が「異常」であると判定される。
【００７４】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００７５】
つづいて、ステップＳ１２により、状態検出部４０からＣＰＵ１０の温度を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（ＣＰＵ１０の温度）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、ＣＰＵの温度が「６０℃を超える」場合は異常状態としてログ出力基準データ３４４の値を「１」に、「６０℃以下」の場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００７６】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、ＣＰＵの温度が「６０℃を超える」ときはログ出力レベル「２」、「５５℃を超え６０℃以下」のときはログ出力レベル「１」、「５５℃以下」のときはログ出力レベル「０」となるよう設定しても良い。
【００７７】
なお、本実施例において、ＣＰＵ１０の温度を検出するためにＡＣＰＩを利用することとして説明したが、例えば、ＣＰＵ内部に備えられた温度センサ（サーマルダイオード）により温度を検出したり、表面に接着された温度センサーにより温度を検出したりする等の他の手段を用いても良いことは勿論である。
【００７８】
〔第５実施例〕
次に、第５実施例として、異常検出を行うための判定パラメータとして、電源にかかる電圧を測定する手段を備えている場合に、電圧を利用する場合について説明する。これは、通常電源にかかる電圧は常に一定の範囲内に収まっているものであり、この範囲を大きく超える場合にはリセットがかかるからである。
【００７９】
本実施例において、状態検出部４０は、別途電圧を測定するための電圧測定部に接続されている。そして、電圧測定部より電源にかかる電圧を取得することにより、電圧を検出する。
【００８０】
また、異常検出プログラム３６は、状態検出部４０から状態値として、電圧を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００８１】
また、第５実施例における判定条件テーブル３６２の一例を図９に示す。図９に示すように、判定パラメータとして「電圧」が設定されている。ここで、本実施例ではシステムの設計上、電圧が通常「１００Ｖ±５Ｖ」となるように設計されている。このとき、条件として電圧が「１００Ｖ±５Ｖ内」となる場合はシステム状態が「正常」であると判定され、「１００Ｖ±５Ｖ外」となる場合はシステム状態が「異常」であると判定される。
【００８２】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００８３】
つづいて、ステップＳ１２により、状態検出部４０から電圧を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（電圧）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、電圧が「１００±５Ｖ外」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「１００±５Ｖ内」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００８４】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、ＣＰＵの温度が「１００±５Ｖ外」のときはログ出力レベル「２」、「１００±２Ｖ〜５Ｖ」のときはログ出力レベル「１」、「１００±２Ｖ内」のときはログ出力レベル「０」となるよう設定しても良い。
【００８５】
〔第６実施例〕
次に、第６実施例として、異常検出を行うための判定パラメータとして、メッセージキュー内のメッセージ数を利用する場合について説明する。これは、アプリケーション間やタスク間、スレッド間でメッセージキューイングを利用してデータ交換、連携動作を行っている場合、メッセージキュー内に処理されずにメッセージが溜まり続ける状態は異常が発生していると考えられるからである。
【００８６】
本実施例において、状態検出部４０は、メッセージキュー内のメッセージ数を検出する。具体的には、プログラム実行中の変数を参照することにより検出する。
【００８７】
また、異常検出プログラム３６は、状態検出部４０から状態値として、メッセージ数を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００８８】
また、第６実施例における判定条件テーブル３６２の一例を図１０に示す。図１０に示すように、判定パラメータとして「メッセージ数」が設定されている。ここで、本実施例では、メッセージキューの数を１つとし、最大メッセージ保持数は２５６であるが、設計上「１２８以上」とならないよう設計されているものとする。このとき、条件としてメッセージ数が「１２８未満」となる場合はシステム状態が「正常」であると判定され、「１２８以上」となる場合はシステム状態が「異常」であると判定される。
【００８９】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００９０】
つづいて、ステップＳ１２により、状態検出部４０からメッセージ数を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（メッセージ数）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、メッセージ数が「１２８以上」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「１２８未満」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００９１】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、メッセージ数が「１２８以上」のときはログ出力レベル「２」、「１２０以上１２８未満」のときはログ出力レベル「１」、「１２０未満」のときはログ出力レベル「０」となるよう設定しても良い。
【００９２】
また、アプリケーション・プログラム内に複数のタスク、複数のメッセージキューが存在し、タスクごとにログ出力基準を設定することができ、メッセージキューを処理するタスクが限られている場合、アプリケーション・プログラムで実行される複数のタスクのうち異常が発生しているタスクを限定することが可能である。この場合にはそのタスクに対してのみログ出力基準変更を行うことができる。
【００９３】
〔第７実施例〕
次に、第７実施例として、異常検出を行うための判定パラメータとして、メッセージがない状態の時間を利用する場合について説明する。これは、第６実施例とは逆に、メッセージが来るはずメッセージキューに、メッセージが来ない状態もアプリケーション・プログラムに異常が発生していると考えられるからである。
【００９４】
本実施例において、状態検出部４０は、メッセージキューに、メッセージがない状態の時間を検出する。具体的には、第６実施例と同様、プログラム実行中の変数を参照することにより検出する。
【００９５】
また、異常検出プログラム３６は、状態検出部４０から状態値として、メッセージが無い時間を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【００９６】
また、第７実施例における判定条件テーブル３６２の一例を図１１に示す。図１１に示すように、判定パラメータとして「メッセージが無い時間」が設定されている。ここで、本実施例では、メッセージキューの数を１つとし、メッセージキューには、「１秒以内」にメッセージが到着する設計となっている。このとき、条件としてメッセージが無い時間が「１秒未満」となる場合はシステム状態が「正常」であると判定され、「１秒以上」となる場合はシステム状態が「異常」であると判定される。
【００９７】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【００９８】
つづいて、ステップＳ１２により、状態検出部４０からメッセージが無い時間を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（メッセージが無い時間）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、メッセージが無い時間が「１秒以上」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「１秒未満」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【００９９】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、メッセージが無い時間が「１秒以上」のときはログ出力レベル「２」、「０．８秒以上１秒未満」のときはログ出力レベル「１」、「０．８秒未満」のときはログ出力レベル「０」となるよう設定しても良い。
【０１００】
〔第８実施例〕
次に、第８実施例として、異常検出を行うための判定パラメータとして、セマフォの待ち時間を利用する場合について説明する。これは、タスク、スレッドを並列処理している環境において、資源に同時アクセスできる上限を規定し、排他区間を確保するためにセマフォを用いている場合、セマフォの待ち時間が増加し続けている状態は、デッドロックに入っている可能性があり、トラブル発生の危険性が高まっていると考えられるからである。
【０１０１】
本実施例において、状態検出部４０は、セマフォの待ち時間を検出する。具体的には、プログラム実行中の変数を参照することにより検出する。
【０１０２】
また、異常検出プログラム３６は、状態検出部４０から状態値として、セマフォの待ち時間を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【０１０３】
また、第８実施例における判定条件テーブル３６２の一例を図１２に示す。図１２に示すように、判定パラメータとして「セマフォの待ち時間」が設定されている。ここで、本実施例では、セマフォの数を１つとし、タスクがセマフォを取得しようとした場合に、待ち時間が「５秒以上」とならない設計となっている。このとき、条件としてメッセージが無い時間が「５秒未満」となる場合はシステム状態が「正常」であると判定され、「５秒以上」となる場合はシステム状態が「異常」であると判定される。
【０１０４】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【０１０５】
つづいて、ステップＳ１２により、状態検出部４０からセマフォの待ち時間を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（セマフォの待ち時間）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、セマフォの待ち時間が「５秒以上」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「５秒未満」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。
【０１０６】
なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。例えば、セマフォの待ち時間が「５秒以上」のときはログ出力レベル「２」、「３秒以上５秒未満」のときはログ出力レベル「１」、「３秒未満」のときはログ出力レベル「０」となるよう設定しても良い。
【０１０７】
〔第９実施例〕
次に、第９実施例として、異常検出を行うための判定パラメータとして、割り込みの頻度（発生回数）を利用する場合について説明する。
【０１０８】
本実施例において、状態検出部４０は、割り込みの頻度として１秒間に発生する割り込みの回数を検出する。具体的には、各割り込み処理内に、割り込みの回数をカウントアップする処理をいれて保存しておき、この回数をプログラム実行中に参照することにより検出する。
【０１０９】
また、異常検出プログラム３６は、状態検出部４０から状態値として、割り込みの頻度を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【０１１０】
また、第９実施例における判定条件テーブル３６２の一例を図１３に示す。図１３に示すように、判定パラメータとして「割り込み発生回数」が設定されている。ここで、本実施例では、割り込み発生回数は通常１秒間あたり「１０回以上２０回以下」となるように設計されている。このとき、条件として割り込み発生回数が「１０回以上２０回以下」の場合はシステム状態が「正常」であると判定され、「１０回未満」又は「２０回を超える」場合はシステム状態が「異常」であると判定される。
【０１１１】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【０１１２】
つづいて、ステップＳ１２により、状態検出部４０から割り込み発生回数を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（割り込み発生回数）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、割り込み発生回数が「１０回未満」又は「２０回を超える」場合には、異常状態としてログ出力基準データ３４４の値を「１」に、「１０回以上２０回以下」の場合は正常状態としてログ出力基準データ３４４の値を「０」とする。なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良いことはもちろんである。
【０１１３】
〔第１０実施例〕
次に、第１０実施例として、異常検出を行うための判定パラメータとして、タスクのスイッチにかかる時間（タスクスイッチ時間）を利用する場合について説明する。これは、複数のタスクが実行されている環境において、タスクの切り替え（スイッチ）に必要な本来一定の時間が必要とされるはずである。しかし、割込み処理が生じたり、他のタスクにＣＰＵが占有されたりするとスイッチ完了までに遅れが生じてしまうと考えられるからである。
【０１１４】
本実施例において、状態検出部４０は、タスクのスイッチにかかる時間を検出する。具体的には、タスクスイッチに要する時間を測定するためにＬｉｎｕｘカーネルにてタスクスイッチ開始と終了を検知して、それぞれにおけるプログラムカウンタを記録しておき、その値より時間に計算しなおすことにより検出する。
【０１１５】
また、異常検出プログラム３６は、状態検出部４０から状態値として、タスクスイッチ時間を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【０１１６】
また、第１０実施例における判定条件テーブル３６２の一例を図１４に示す。図１４に示すように、判定パラメータとして「タスクスイッチ時間」が設定されている。ここで、本実施例では、アプリケーション・プログラム３４内に存在するタスクが２個であり、タスクスイッチ時間は「１００ｍｓ以内」になるよう設計されている。このとき、条件としてタスクスイッチ時間が「１００ｍｓ以内」となる場合はシステム状態が「正常」であると判定され、「１００ｍｓ超」となる場合はシステム状態が「異常」であると判定される。
【０１１７】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【０１１８】
つづいて、ステップＳ１２により、状態検出部４０からタスクスイッチ時間を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（タスクスイッチ時間）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、タスクスイッチ時間が「１００ｍｓ超」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「１００ｍｓ以内」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良いことはもちろんである。
【０１１９】
〔第１１実施例〕
次に、第１１実施例として、異常検出を行うための判定パラメータとして、ＤＭＡによるバス占有時間を利用する場合について説明する。ここで、ＤＭＡとは「Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ」の略で、システムのＣＰＵを介すことなく、デバイスからシステムのメモリ（またはその逆）へのデータ転送を行なう方法である。そして、ＤＭＡが稼動してバスが占有され続けている場合、ＣＰＵの管理していない状況でデバイスが暴走し、システムに異常が発生している状態であると考えられるからである。
【０１２０】
本実施例において、状態検出部４０は、ＤＭＡによるバス占有時間を検出するためのバス占有時間検出部に接続されている。そして、バス占有時間検出部よりバス占有時間を検出する。
【０１２１】
また、異常検出プログラム３６は、状態検出部４０から状態値として、ＤＭＡによるバス占有時間を定期的に取得し、判定条件テーブル３６２に基づいて、システムの状態（アプリケーション・プログラム３４の状態）が異常であるか否かの判定を行う。そして、システムの状態に応じてログ出力基準書換手段３６６を実行する。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【０１２２】
また、第１１実施例における判定条件テーブル３６２の一例を図１５に示す。図１５に示すように、判定パラメータとして「ＤＭＡバス占有時間」が設定されている。ここで、本実施例では、ＤＭＡが稼働してバスが占有されている状態が「１秒未満」となるように設計となっている。このとき、条件としてＤＭＡバス占有時間が「１秒未満」となる場合はシステム状態が「正常」であると判定され、「１秒以上」となる場合はシステム状態が「異常」であると判定される。
【０１２３】
本実施例における異常検出処理の動作を、図２の動作フローを用いて説明する。まず、ステップＳ１０において、判定条件テーブル３６２から、判定パラメータ等を読み出す。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。またシステムの状態が「異常状態」である場合はログ出力レベルを「１」に変更すると定めておく。なお、システムが「正常状態」である場合は、ログ出力レベルは「０」となる。
【０１２４】
つづいて、ステップＳ１２により、状態検出部４０からＤＭＡバス占有時間を状態値として一定時間間隔ごとに取得する。そして、ステップＳ１４において、ステップＳ１２で取得した状態値（ＤＭＡバス占有時間）に基づき、システム状態の判定を行う。ここで、ステップＳ１０において定めたように、ＤＭＡバス占有時間が「１秒以上」となる場合は異常状態としてログ出力基準データ３４４の値を「１」に、「１秒未満」となる場合は正常状態としてログ出力基準データ３４４の値を「０」とする。なお、本実施例では、しきい値を一つとしているが、段階的に設定されても良い。
【０１２５】
〔第１２実施例〕
次に、第１２実施例として、異常検出を行うための判定パラメータとして、スタック領域の状態を利用する場合について説明する。ここで、アプリケーション・プログラム３４が引き起こす異常動作にスタック領域の拡大によりアプリケーション・プログラム３４が使用するメモリの内容が上書きされてしまうという現象がある。この異常動作を事前に検知するために予めスタック領域を特徴的なパターンで埋めておき、定期的にスタック領域のメモリ内容を読み出すことにより、どの部分までスタック領域の使用が進んでいるかをチェックし、異常の判断に利用することとする。
【０１２６】
本実施例において、状態検出部４０は、アプリケーション・プログラム３４が利用するメモリの値を参照することによりシステムの状態を検出する。
【０１２７】
また、異常検出プログラム３６は、図１６の動作フローに示した処理で実行される。具体的には、アプリケーション・プログラム３４が使用するスタック領域の大きさを「４ｋｂｙｔｅ」と定め、「１００ｂｙｔｅ」の余裕がある設計となっている。そして、当該スタック領域には、特徴的なパターンとして「０」が格納されている。ここで、異常検出プログラム３６は、判定パラメータとして、上記「１００ｂｙｔｅ」部分を読み出すことが設定されている。そして、スタック領域が全て「０」である正常な状態を「ＳＡＦＥ」とし、「０」以外の値が書き込まれている状態を「ＥＲＲＯＲ」と検出する。そして、「ＥＲＲＯＲ」の場合、ログ出力基準書換手段３６６を実行し、ログ出力基準を上げる。なお、異常検出プログラム３６も、アプリケーション・プログラム３４内のタスクと同様Ｌｉｎｕｘカーネルによって並行して実行されるよう管理される。
【０１２８】
本実施例における異常検出処理の動作を、図１６の動作フローを用いて説明する。まず、ステップＳ２０において、スタック領域の残り「１００ｂｙｔｅ」部分を全て「０」の書き込みを行う。そして、ログ出力基準データ３４４の初期値を最低値である「０」とする。
【０１２９】
つづいて、ステップＳ２２により、状態検出部４０からスタック領域を検出する。そして、「０」が書き込まれた「１００ｂｙｔｅ」の部分が総て「０」である場合には「ＳＡＦＥ」と判定し、「０」以外の値が書き込まれている場合には「ＥＲＲＯＲ」と判定される。そして、「０」以外の値が書き込まれている場合、すなわち「ＥＲＲＯＲ」の場合には（ステップＳ２４；Ｙｅｓ）、ログ出力基準書換手段３６６を実行することにより、ログ出力基準を上げる処理を実行する（ステップＳ２６）。
【０１３０】
〔第１３実施例〕
次に、第１３実施例として、異常検出を行うための判定パラメータとして、ページフォルトの割込みを利用する場合について説明する。ここで、物理メモリに存在しないメモリページに対してアクセスがあった際にページフォルトという割込み処理が発生する。スタック領域の危険部分へのアクセスが行われた際にＯＳで行われるページフォルト処理にログ出力基準を上げる処理を埋め込んでおくことにより危険性が高まった際のログ出力基準変更が可能となるである。
【０１３１】
本実施例において、状態検出部４０は、Ｌｉｎｕｘカーネル３２から、アプリケーション・プログラム３４によりページフォルトの割込みが発生したことを検出する。
【０１３２】
また、本実施例における異常検出プログラム３６は、図１７の動作フローに示した処理で実行される。具体的には、アプリケーション・プログラム３４が使用するスタック領域の大きさを「４ｋｂｙｔｅ」と定め、「１００ｂｙｔｅ」の余裕がある設計となっている。そして、当該スタック領域の危険部分へのアクセスがあると、ページフォルトの割込みが発生したと判定し、ログ出力基準を上げる。
【０１３３】
本実施例における異常検出処理の動作を、図１７の動作フローを用いて説明する。まず、ステップＳ３０において、スタック領域のどの部分にアクセスした場合に、トラブル発生の危険性があるとするかを定め、設定する。
【０１３４】
つづいて、ステップＳ３２により、状態検出部４０はページフォルトを検出する。ここで、ページフォルトの割込みが発生したことを検出すると（ステップＳ３４；Ｙｅｓ）、ログ出力基準書換手段３６６を実行することにより、ログ出力基準を上げる処理を実行する（ステップＳ３６）。
【０１３５】
〔第１４実施例〕
次に、第１４実施例として、異常検出を行うための判定パラメータとして、過去に発生した異常発生時のプログラムヒストリを利用する場合について説明する。
【０１３６】
本実施例において、状態検出部４０は、過去に異常の発生したプログラムカウンタの動き方を監視し、同様のプログラムカウンタの動作を検出することにより、異常検出を行う。
【０１３７】
本実施例における異常検出処理の動作を、図１７の動作フローを用いて説明する。まず、ステップＳ３０において、過去に異常が発生した場合のプログラムカウンタの動きを読み出し、状態検出部４０に監視させる。
【０１３８】
つづいて、ステップＳ３２により、状態検出部４０は過去に異常が発生した場合のプログラムカウントと同じ動きがあるか否かを検出する。ここで、同じ動きを検出すると（ステップＳ３４；Ｙｅｓ）、ログ出力基準書換手段３６６を実行することにより、ログ出力基準を上げる処理を実行する（ステップＳ３６）。
【０１３９】
〔変形例〕
上述した実施形態では、本発明をＬｉｎｕｘを内蔵したテレビ受像機に適用した例を説明したが、本発明が適用可能な範囲は上記に限定されるものではなく、携帯電話や、コンピュータ、ＰＤＡ等の電子機器に適用可能である。
【０１４０】
一例として、携帯電話に適用した場合、アプリケーション・プログラムはマイクからの音声の入力、およびスピーカからの音声の出力を制御し、その入出力データをアンテナ経由で送受信しており、テレビシステムとは異なる機能を果たしている。しかし、テレビシステムの場合と同様のログ出力命令を有しているため、デバッグのために異常検出プログラム導入することにより、テレビシステムと同様にログ出力を行わせることが可能である。
【０１４１】
また、上述した実施形態では、ＯＳとしてＬｉｎｕｘを一例に説明したが、これに限定されるものではなく、他のＯＳでも適用可能なことは勿論である。
【０１４２】
また、上述した実施形態において、判定パラメータの判断に用いる値はアプリケーション・プログラム３４の開始時に判定条件テーブル３６２に基づいて設定することとして説明したが、アプリケーション・プログラム３４の実行中に動的に変更することとしても良い。
【０１４３】
また、上述した実施形態の図２において、ステップＳ１２において取得された状態値に応じて、ステップＳ１４においてその都度システムの状態が判定され、当該システムの状態に応じてステップＳ１６においてログ出力基準が更新されることとして説明したが、ステップＳ１４におけるシステム状態の判定は、一定期間状態値の異常が検出された場合に異常状態と判定することとしても良いことは勿論である。
【０１４４】
例えば、第２実施例においては、ＣＰＵ使用率が「３秒間」、「９５％以上」と検出された場合にはシステムの状態が異常であると判定したり、第４実施例においては、ＣＰＵの温度が「５秒間」、「６０℃を超える」場合に、システムの状態が異常であると判定したりしても良い。
【図面の簡単な説明】
【０１４５】
【図１】本実施形態におけるテレビ受像機の構成を示した図である。
【図２】本実施形態における異常検出処理の動作フローを示した図である。
【図３】第１実施例における判定条件テーブルの一例を示した図である。
【図４】第１実施例における動作を説明するための図である。
【図５】第１実施例における動作を説明するための図である。
【図６】第２実施例における判定条件テーブルの一例を示した図である。
【図７】第３実施例における判定条件テーブルの一例を示した図である。
【図８】第４実施例における判定条件テーブルの一例を示した図である。
【図９】第５実施例における判定条件テーブルの一例を示した図である。
【図１０】第６実施例における判定条件テーブルの一例を示した図である。
【図１１】第７実施例における判定条件テーブルの一例を示した図である。
【図１２】第８実施例における判定条件テーブルの一例を示した図である。
【図１３】第９実施例における判定条件テーブルの一例を示した図である。
【図１４】第１０実施例における判定条件テーブルの一例を示した図である。
【図１５】第１１実施例における判定条件テーブルの一例を示した図である。
【図１６】本実施形態における異常検出処理の動作フローを示した図である。
【図１７】本実施形態における異常検出処理の動作フローを示した図である。
【図１８】従来例におけるテレビ受像機の構成を示した図である。
【図１９】従来例におけるログ出力命令レベルテーブルの構成を示した図である。
【図２０】従来例におけるアプリケーション・プログラムの動作フローを示した図である。
【図２１】従来における動作を説明するための図である。
【符号の説明】
【０１４６】
１  テレビ受像機
１０  ＣＰＵ
１２  チューナ部
１４  デコード部
１６  記憶部
１８  ログ出力部
２０  表示部
２２  音声出力部
３０  ＨＤＤ
３２  Ｌｉｎｕｘカーネル
３４  アプリケーション・プログラム
３４２  ログ出力命令レベルテーブル
３４４  ログ出力基準データ
３６  異常検出プログラム
３６２  判定条件テーブル
３６４  システム状態判定手段
３６６  ログ出力書換手段
４０  状態検出部
【図１】
2009110156.tif 000003
【図２】
2009110156.tif 000004
【図３】
2009110156.tif 000005
【図４】
2009110156.tif 000006
【図５】
2009110156.tif 000007
【図６】
2009110156.tif 000008
【図７】
2009110156.tif 000009
【図８】
2009110156.tif 000010
【図９】
2009110156.tif 000011
【図１０】
2009110156.tif 000012
【図１１】
2009110156.tif 000013
【図１２】
2009110156.tif 000014
【図１３】
2009110156.tif 000015
【図１４】
2009110156.tif 000016
【図１５】
2009110156.tif 000017
【図１６】
2009110156.tif 000018
【図１７】
2009110156.tif 000019
【図１８】
2009110156.tif 000020
【図１９】
2009110156.tif 000021
【図２０】
2009110156.tif 000022
【図２１】
2009110156.tif 000023