JP2018097695A - 監視装置、監視方法及び監視プログラム - Google Patents

Abstract

【課題】デバイス上のアプリケーション（アプリ）の動作を監視する監視装置を提供する。【解決手段】監視装置３において、状態遷移モデル記憶部３１がアプリ（ＩｏＴ分散アプリ）２１の状態遷移モデルを記憶し、ログ記憶部３２がアプリの動作状況ログを記憶する。状態判定部３６が、デバイス２から状態通知を受信すると、動作状況ログからアプリの現在状態（ｂ）を特定し、状態通知からアプリの現在状態（ａ）を特定する。状態判定部は、状態通知からアプリの状態遷移モデルを特定する。状態判定部は、現在状態（ｂ）から現在状態（ａ）への遷移に付加されている遷移条件を満たさない場合に、アプリの動作が正常でないと判定する。【選択図】図１

Description

本発明は、監視装置、監視方法及び監視プログラムに関する。

様々なデバイスをインターネットで接続し、デバイスから得られるセンサー情報等を利用してサービスの提供等を行うＩｏＴ（Internet of Things）技術の利用が進んでいる。

また、スマートフォンが実行するアプリケーションの挙動が予めアプリケーション自身によりスマートフォンに登録された挙動と異なる場合には、当該アプリケーションの再起動を実施することで、アプリケーションの安定稼働を実現する技術がある。

また、監視対象のログ情報を読み込んで分類し、分類結果を基に平常時のログ遷移モデルを生成し、ログ分類結果とログ遷移モデルからログ遷移を分析し、ログ変化があった時に監視対象へ診断指示を行い、監視対象からの情報を基に障害有無を判定する技術がある。この技術によれば、監視対象の障害発生に関して精度良い判断を行うことができる。

また、基準となる第１状態遷移確率モデルと、ソフトウェアの運用中に求めた第２状態遷移確率モデルとで、あらかじめ設定した状態遷移毎の遷移確率を比較することにより異常度を求め、異常度と閾値を比較して異常であるか否かを判断する技術がある。この技術によれば、予想しないソフトウェアの異常動作に対しても異常を検知することができる。

また、コンポーネント間のメッセージ送受信に関わる記述を用いて各コンポーネントの抽象化済状態遷移モデルを作成し、該抽象化済状態遷移モデルを結合し、メッセージログを用いてさらに検出範囲を限定したシステム状態遷移モデルを作成する技術がある。この技術によれば、システム状態遷移モデルに対してデッドロック検出を行うことができる。

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

ＩｏＴでは、ネットワークやデバイスの接続状態を管理することはできるが、デバイス上のアプリケーションが正しく動作しているかを把握することが困難であるという問題がある。アプリケーションによって挙動は異なるため、アプリケーションが正しく動作しているかは開発者がアプリケーションの実行ログ等を見て判断する必要があり、接続されるデバイスの数が増えると対処が難しい。

本発明は、１つの側面では、デバイス上のアプリケーションの動作を監視することを目的とする。

１つの態様では、監視装置は、ログ記憶部と、第１特定部と、第２特定部と、第３特定部と、判定部と、通知部とを有する。ログ記憶部は、複数のデバイスから送信された状態通知に含まれるアプリの状態に基づいて各デバイスで動作するアプリの状態を記憶する。第１特定部は、複数のデバイスのうちの１つである第１デバイスから状態通知を受信すると、受信した状態通知に基づいてログ記憶部を検索して該第１デバイスで動作する第１アプリの第１状態を特定する。第２特定部は、受信した状態通知に含まれるアプリの状態を第１アプリの第２状態として特定する。第３特定部は、受信した状態通知に基づいて第１アプリに対応づけられた状態遷移モデルを特定する。判定部は、第１状態から第２状態への遷移が状態遷移モデルで定義された状態遷移に関する所定の条件を満たすか否かを判定する。通知部は、判定部により所定の条件を満たさないと判定された場合に、第１アプリにエラーが発生したことを通知する。

１つの側面では、本発明は、デバイス上のアプリケーションの動作を監視することができる。

図１は、実施例に係るＩｏＴシステムの構成を示す図である。 図２は、アプリの状態遷移モデルの一例を示す図である。 図３は、アプリの状態遷移モデルの定義例を示す図である。 図４は、図２に示したアプリ状態遷移モデルに対応するＸＭＬ記述を示す図である。 図５は、無線光センサーを用いて照度を測定して送信するアプリの状態遷移モデルの例を示す図である。 図６は、図５に示したアプリ状態遷移モデルに対応するＸＭＬ記述を示す図である。 図７は、その他の遷移条件の記述例を示す図である。 図８は、ログ記憶部の一例を示す図である。 図９は、統計モデル記憶部の一例を示す図である。 図１０は、アプリ状態可視化の画面例を示す図である。 図１１は、状態通知の受信からアプリの動作判定までの処理の流れを示すシーケンス図である。 図１２は、統計モデルを構築する処理の流れを示すシーケンス図である。 図１３は、アプリ状態可視化の処理の流れを示すシーケンス図である。 図１４は、状態通知受信時の状態判定部による処理のフローを示すフローチャートである。 図１５は、タイマー起動時の状態判定部による処理のフローを示すフローチャートである。 図１６は、実施例に係る監視プログラムを実行するコンピュータのハードウェア構成を示す図である。

以下に、本願の開示する監視装置、監視方法及び監視プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係るＩｏＴシステムの構成について説明する。図１は、実施例に係るＩｏＴシステムの構成を示す図である。図１に示すように、実施例に係るＩｏＴシステム１は、デバイス２と監視装置３とを有する。デバイス２と監視装置３はインターネット等のネットワークで接続される。なお、ここでは説明の便宜上、１台のデバイス２のみを示したが、ＩｏＴシステム１は、複数のデバイス２を有する。

デバイス２は、通信機能を備え、監視装置３とネットワークを介して通信する。デバイス２は、例えば、温度センサー、光センサー等のセンサーを備え、センサーが検知した温度、照度等をインターネットを介して温度情報、照度情報等を利用する情報処理装置に送信する。

デバイス２は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等の処理装置を有し、デバイス２では、ＩｏＴ分散アプリ２１とログ収集プログラム２２が動作する。

ＩｏＴ分散アプリ２１は、分散配置されるデバイス２で動作するアプリケーションである。以下では、ＩｏＴ分散アプリ２１を単にアプリ２１と表す。アプリ２１は、例えば、温度センサーを用いて測定した温度をインターネットを介して温度情報を利用する情報処理装置に送信する。

ログ収集プログラム２２は、アプリ２１のログを収集し、監視装置３に状態通知として送信する。状態通知には、デバイス２を識別するためのデバイスＩＤ、アプリ２１の状態、ログを収集した時刻の情報が含まれる。

監視装置３は、状態遷移モデルを用いてアプリ２１の動作を監視する装置である。監視装置３は、状態遷移モデル記憶部３１と、ログ記憶部３２と、通知設定情報記憶部３３と、統計モデル記憶部３４とを有する。また、監視装置３は、通信部３５と、状態判定部３６と、通知設定管理部３７と、時間監視部３８と、統計モデル構築部３９と、状態遷移設定部４０と、状態可視化部４１とを有する。

状態遷移モデル記憶部３１は、複数の種類のアプリ２１について状態遷移モデルを記憶する。図２は、アプリ２１の状態遷移モデルの一例を示す図である。図２は、温度センサーを用いて温度を測定して送信するアプリ２１の状態遷移モデルを示す。図２に示すように、状態遷移モデルには、アプリ種別テンプレート部分４６とアプリ固有拡張部分４７とがある。

アプリ種別テンプレート部分４６は、種別が同じアプリ２１で共通な部分である。アプリ固有拡張部分４７は、アプリ２１に固有な部分であり、アプリ２１用に拡張された部分である。図２では、アプリ種別テンプレート部分４６には、ＧＷ起動、ＶＭ起動、アプリ起動、ミドルエラー、アプリエラーの５つの状態がある。

ＧＷ起動は、通信を行うためのゲートウェイが起動された状態である。ＶＭ起動は、アプリ２１を実行するＪａｖａ（登録商標）仮想マシンが起動された状態である。アプリ起動は、アプリ２１が起動された状態である。ミドルエラーは、ミドルウェアにエラーが発生した状態である。アプリエラーは、アプリ２１にエラーが発生した状態である。

状態間の矢印は、状態遷移を表す。例えば、ＶＭ起動の状態でエラーが発生すると、アプリ２１は、ミドルエラーの状態に遷移する。また、ＶＭ起動の状態は３０秒以内にアプリ起動に遷移する。「３０秒以内」は、時間制限を表す。

アプリ固有拡張部分４７には、温度センサー準備、温度データ送信、データ送信停止の３つの状態がある。温度センサー準備は、温度センサーによる温度測定の準備ができた状態である。温度データ送信は、温度データを送信する状態である。データ送信停止は、温度データ送信後にデータ送信を停止している状態である。例えば、データ送信停止の状態にあるアプリ２１は、１分以内に温度データ送信の状態に遷移する。

図３は、アプリ２１の状態遷移モデルの定義例を示す図である。図３において、矢頭がひし形の矢印は、全体と部分の集約関係を表し、矢頭側が全体であり、矢尾側が部分である。矢尾側の＊は、全体が複数の部分から構成されることを表す。矢頭が三角の矢印は、汎化の関係を表し、矢印の方向が汎化の方向を表す。破線の矢印は継承関係を表す。

図３に示すように、アプリ２１の状態遷移モデルは、複数の状態と遷移を持つ。温度センサー遷移モデル、光センサー遷移モデルは、状態遷移モデルを継承する。なお、アプリ２１の状態遷移モデルにおける遷移の種類は、基本となる遷移モデルを継承して拡張されている。

図４は、図２に示したアプリ状態遷移モデルに対応するＸＭＬ（eXtensible Markup Language）記述を示す図である。図２に示したアプリ状態遷移モデルは、図４に示すＸＭＬ記述により状態遷移モデル記憶部３１に記憶される。

図４において、＜ｍｏｄｅｌ：ＳｔａｔｅＭｏｄｅｌ ｉｄ＝“ｔｅｍｐ−ｓｅｎｎｓｏｒ”＞は、状態遷移モデルの識別子が“ｔｅｍｐ−ｓｅｎｎｓｏｒ”であることを表す。＜Ｓｔａｔｅ ｉｄ＝“ｔｓ０１” ｎａｍｅ＝“ＧＷ起動”／＞は、状態遷移モデルに含まれる状態を定義し、状態の識別子が“ｔｓ０１”であり、状態の名前が“ＧＷ起動”であることを表す。他の状態も同様に定義される。

＜Ｔｒａｎｓ ｉｄ＝“ｔ０１” ｆｒｏｍ＝“ｔｓ０１” ｔｏ＝“ｔｓ０２” ｔｙｐｅ＝“通常”／＞は、状態遷移モデルに含まれる状態遷移を定義する。この定義は、状態の識別子が“ｔ０１”であり、“ｔｓ０１”から“ｔｓ０２”の遷移であり、遷移の種類が“通常”であることを表す。“通常”は、遷移に条件のない遷移であることを示す。

＜Ｔｒａｎｓ ｉｄ＝“ｔ０２” ｆｒｏｍ＝“ｔｓ０２” ｔｏ＝“ｔｓ０３” ｔｙｐｅ＝“時間制限”＞＜Ｌｉｍｉｔ ｔｉｍｅ＝“３００００ｍｓｅｃ”／＞の“時間制限”は、遷移に時間制限があることを表す。また、＜Ｌｉｍｉｔ ｔｉｍｅ＝“３００００ｍｓｅｃ”／＞は、制限時間が３０秒であることを示す。他の状態遷移も同様に定義される。

図５は、アプリ状態遷移モデルの他の例を示す図である。図５は、無線光センサーを用いて照度を測定して送信するアプリ２１の状態遷移モデルの例を示す。図５に示すように、アプリ種別テンプレート部分４８には、ＧＷ起動、無線接続、アプリ起動、ミドルエラー、アプリエラーの５つの状態がある。無線接続は、無線光センサと無線で接続された状態である。アプリ固有拡張部分４９には、照度データ送信、データ送信停止の２つの状態がある。照度データ送信は、照度データを送信する状態である。図６は、図５に示したアプリ状態遷移モデルに対応するＸＭＬ記述を示す図である。

図７は、その他の遷移条件の記述例を示す図である。図７において、“プロパティ条件”は、プロパティの値に応じた遷移条件があることを表す。＜Ｃｏｎｄ ｖａｌｕｅ＝“ｔ＜２０”／＞は、プロパティｔの値が２０より小さいことが遷移条件であることを表す。

図１に戻って、ログ記憶部３２は、アプリ２１に関してデバイス２から送信された状態通知に含まれる情報を動作状況ログとして記憶する。図８は、ログ記憶部３２の一例を示す図である。図８に示すように、ログ記憶部３２は、ＩＤと、種別と、エリアと、現在状態と、最終更新と、通知設定とをデバイス２毎に記憶する。

ＩＤは、デバイス２を識別する識別子である。種別は、デバイス２で動作するアプリ２１の状態遷移モデルを示す。エリアは、デバイス２が配置されている場所を示す。現在状態は、デバイス２の現在の状態を示す。最終更新は、デバイス２の状態が最後に更新された時刻を示す。

通知設定は、デバイス２へ通知する内容を示す。通知設定には、例えば、「通常」、「詳細リクエスト」がある。「通常」は、通常の情報を状態通知として送信するようにデバイス２に通知する。通常の情報には、デバイスＩＤ、アプリ２１の現在状態、時刻情報が含まれる。「詳細リクエスト」は、トレースログ、プロセス一覧を収集して送信するようにデバイス２に通知する。

例えば、ＩＤが「機器＃１」であるデバイス２は、温度センサーで測定された温度を送信するアプリ２１を動作させ、「事務所＃１」に配置される。アプリ２１の状態は「ｔｓ０６」であり、状態の最終更新が行われた時刻は「１０：１５：３０」であり、通知設定は「通常」である。

通知設定情報記憶部３３は、デバイス２へ通知する内容をデバイス２毎に記憶する。通知設定情報記憶部３３は、例えば、「通常」、「詳細リクエスト」をデバイス２毎に記憶する。

統計モデル記憶部３４は、デバイス２に関する統計的な情報を記憶する。図９は、統計モデル記憶部３４の一例を示す図である。図９は、デバイス２が配置されたエリア毎にデバイス２の状態毎にデバイス数を記憶する場合を示す。

図９に示すように、統計モデル記憶部３４は、種別と、エリアと、現在状態と、デバイス数と、最終更新をエリア毎現在状態毎に記憶する。デバイス数は、エリア毎現在状態毎のデバイス２の数である。例えば、温度センサーで測定された温度を送信するアプリ２１は、「事務所＃１」に「ｔｓ０６」のものが１つあり、「ｔｓ０５」のものが２つある。

通信部３５は、デバイス２と通信を行う。通信部３５は、例えば、アプリ２１又はログ収集プログラム２２から、アプリ２１の状態通知を受信し、受信したを状態通知を状態判定部３６に渡す。また、通信部３５は、ログ収集プログラム２２から、通知設定の取得要求を受信し、通知設定情報記憶部３３の設定通知をログ収集プログラム２２に送信する。

状態判定部３６は、通信部３５からアプリ２１の状態通知を受信すると、受信した状態通知に含まれるアプリ２１の現在状態、ログ記憶部３２が記憶するアプリ２１の現在状態及び状態遷移モデル記憶部３１に基づいて、アプリ２１の動作を判定する。すなわち、状態判定部３６は、ログ記憶部３２が記憶するアプリ２１の現在状態から、受信した状態通知に含まれるアプリ２１の現在状態への遷移がアプリ２１の状態遷移モデルに定義されているか否かに基づいてアプリ２１の動作が正しいか否かを判定する。

状態判定部３６は、第１特定部３６ａと、第２特定部３６ｂと、第３特定部３６ｃと、判定部３６ｄと、通知部３６ｅとを有する。

第１特定部３６ａはデバイス２から送信された状態通知を通信部３５から受け取ると、状態通知に含まれるデバイスＩＤを用いてログ記憶部３２を検索し、デバイス２で動作するアプリの現在状態（ｂ）を特定する。

第２特定部３６ｂは、状態通知に含まれる現在状態（ａ）を特定する。第３特定部３６ｃは、状態遷移モデル記憶部３１を参照し、状態通知に含まれるデバイスＩＤに対応する状態遷移モデルを特定する。

判定部３６ｄは、第１特定部３６ａにより特定された現在状態（ｂ）から第２特定部３６ｂにより特定された現在状態（ａ）への遷移があるか否かを判定し、ない場合には、アプリ２１の動作が異常であると判定する。

また、判定部３６ｄは、アプリ２１の遷移に遷移条件が付加されている場合には、遷移条件を満たすか否かを判定し、満たさない場合には、アプリ２１の動作が正しくないと判定する。

通知部３６ｅは、判定部３６ｄによりアプリ２１の動作に異常があると判定された場合に、表示装置にアプリ２１の動作に異常があることを表示する。

また、状態判定部３６は、一定時間毎に時間監視部３８により起動され、ログ記憶部３２が記憶するアプリ２１の現在状態及び状態遷移モデル記憶部３１に基づいて、アプリ２１の動作を判定する。すなわち、状態判定部３６は、ログ記憶部３２が記憶するアプリ２１の現在状態から他の状態への遷移を状態遷移モデル記憶部３１から探し、探した遷移に時間制限がある場合に、時間制限を超えたか否かを判定する。そして、状態判定部３６は、時間制限を超えた場合には、アプリ２１の動作が正しくないと判定する。

通知設定管理部３７は、通知設定情報記憶部３３の通知設定を管理する。例えば、通知設定管理部３７は、状態判定部３６がアプリ２１の動作が正しくないと判定した場合に、状態判定部３６の指示に基づいて、アプリ２１に対応する通知設定を「詳細リクエスト」に設定する。

時間監視部３８は、時間を監視し、一定時間毎に状態判定部３６及び統計モデル構築部３９を起動する。状態判定部３６と統計モデル構築部３９を起動するタイミング及び時間間隔は、同じでもよく、異なってもよい。

統計モデル構築部３９は、ログ記憶部３２に基づいてエリア毎現在状態毎のデバイス数を集計し、統計モデル記憶部３４に格納する。また、統計モデル構築部３９は、定義されたエラー状態に集計結果がなった場合に、エラー通知を画面に表示する。例えば、統計モデル構築部３９は、１０％のデバイス２のアプリ２１がエラー状態になったら緊急通知を表示装置に表示する。

状態遷移設定部４０は、ユーザからの指示に基づいて、状態遷移モデル記憶部３１にアプリ２１の状態遷移モデルを設定する。また、状態遷移設定部４０は、ユーザからの指示に基づいて、状態遷移モデル記憶部３１が記憶する状態遷移モデルを削除又は更新する。

状態可視化部４１は、統計モデル記憶部３４の情報に基づいて、アプリ２１の状態を可視化して表示装置に表示する。図１０は、アプリ状態可視化の画面例を示す図である。図１０は、あるエリアについて、各状態にあるデバイス２の割合を示す。図１０に示すように、アプリ２１がアプリ起動の状態にあるデバイス２は２５％であり、アプリ２１が温度データ送信の状態にあるデバイス２は５０％であり、アプリ２１がデータ送信停止の状態にあるデバイス２は２５％である。

次に、状態通知の受信からアプリ２１の動作判定までの処理の流れについて説明する。図１１は、状態通知の受信からアプリ２１の動作判定までの処理の流れを示すシーケンス図である。なお、ここでは、状態通知に含まれる現在状態への遷移がアプリ状態遷移モデルに定義され、遷移条件がある場合について説明する。

図１１に示すように、通信部３５は、デバイス２から状態通知を受信する（ｔ１）と、受信した状態通知を状態判定部３６に渡す（ｔ２）。すると、状態判定部３６は、状態通知を送信したデバイス２の現在状態をログ記憶部３２から取得し（ｔ３〜ｔ４）、取得した現在状態を遷移元とし、受信した状態通知に含まれる現在状態を遷移先とする遷移の遷移条件を取得する（ｔ５〜ｔ６）。

そして、状態判定部３６は、取得した遷移条件の条件判定を行う（ｔ７）。そして、遷移条件が満たされれば、状態判定部３６は、受信した状態通知に含まれる現在状態への状態更新をログ記憶部３２に対して行う（ｔ８〜ｔ９）。

このように、状態判定部３６は、遷移条件の条件判定を行うことによって、アプリ２１の動作異常を検出することができる。なお、状態判定部３６は、状態通知の受信とは独立に一定時間毎に時間監視部３８からの状態確認通知により起動され（ｔ１０）、遷移条件が満たされているか否かをチェックする。

次に、統計モデルを構築する処理の流れについて説明する。図１２は、統計モデルを構築する処理の流れを示すシーケンス図である。図１２に示すように、統計モデル構築部３９は、時間監視部３８により一定時間毎に処理起動される（ｔ１１）と、状態遷移モデル記憶部３１からアプリ２１の状態リストを取得する（ｔ１２〜ｔ１３）。

そして、統計モデル構築部３９は、ログ記憶部３２から状態毎にデータを取得し（ｔ１４〜ｔ１５）、取得したデータを用いてエリア毎にデータ集計を行う（ｔ１６）。そして、統計モデル構築部３９は、状態毎、エリア毎のデバイス数を統計モデル記憶部３４に登録する（ｔ１７〜ｔ１８）。そして、統計モデル構築部３９は、定義されたエラー状態になっているか否かを判定し、定義されたエラー状態になっている場合には、緊急通知を表示装置に表示する（ｔ１９）。

このように、統計モデル構築部３９が統計モデルを構築して統計モデル記憶部３４に登録することで、状態可視化部４１は、アプリ２１の状態を可視化して表示することができる。また、統計モデル構築部３９が、定義されたエラー状態になっている場合に、緊急通知を表示装置に表示することで、エラーが特定の場所で同時多発している等の状況をユーザに認識させることができる。

次に、アプリ状態可視化の処理の流れについて説明する。図１３は、アプリ状態可視化の処理の流れを示すシーケンス図である。図１３に示すように、状態可視化部４１は、ユーザから全体可視化指示を受け取る（ｔ２１）と、状態遷移モデル記憶部３１から状態リストを取得する（ｔ２２〜ｔ２３）。

そして、状態可視化部４１は、統計モデル構築部３４から状態毎のデバイス数を取得する（ｔ２４〜ｔ２５）。そして、状態可視化部４１は、全体数を集計し、各状態の割合を表示装置に表示する（ｔ２６〜ｔ２７）。

そして、状態可視化部４１は、ユーザからエリア絞り込み指示を受け取る（ｔ２８）と、状態遷移モデル記憶部３１から状態リストを取得する（ｔ２９〜ｔ３０）。

そして、状態可視化部４１は、統計モデル構築部３４から特定エリアの状態毎のデバイス数を取得する（ｔ３１〜ｔ３２）。そして、状態可視化部４１は、特定エリアの全体数を集計し、各状態の割合を表示装置に表示する（ｔ３３〜ｔ３４）。

そして、状態可視化部４１は、ユーザから詳細表示指示を受け取る（ｔ３５）と、状態遷移モデル記憶部３１から状態リストを取得する（ｔ３６〜ｔ３７）。そして、状態可視化部４１は、ログ記憶部３２から特定のデバイスの情報を取得し（ｔ３８〜ｔ３９）、表示装置に表示する（ｔ４０）。

このように、状態可視化部４１が状態毎あるいはエリア毎状態毎にアプリ２１の状態表示するので、ユーザは、分散配置された複数のデバイス２で動作するアプリ２１の状態を全体的に把握することができる。

次に、状態通知受信時の状態判定部３６による処理のフローについて説明する。図１４は、状態通知受信時の状態判定部３６による処理のフローを示すフローチャートである。図１４に示すように、状態判定部３６は、デバイス２から状態通知を受信すると、状態通知からアプリ２１の現在状態（ａ）を取得する（ステップＳ１）。

そして、状態判定部３６は、動作状況ログをデバイスＩＤで検索して、対応するアプリ２１の現在状態（ｂ）を取得する（ステップＳ２）。そして、状態判定部３６は、動作状況ログを用いてデバイスＩＤに対応する種別を特定し、特定した種別に対応する状態遷移モデルのＸＭＬ記述を取得する（ステップＳ３）。

そして、状態判定部３６は、状態遷移モデルのＸＭＬ記述から、遷移元（ｆｒｏｍ）が現在状態（ｂ）と一致する遷移（Ｔｒａｎｓ）を取得する（ステップＳ４）。そして、状態判定部３６は、取得した遷移に遷移先（ｔｏ）が状態通知に含まれる現在状態（ａ）と一致するものがあるか否かを判定し（ステップＳ５）、一致するものがない場合には、ステップＳ１０へ進む。

一方、一致するものがある場合には、状態判定部３６は、一致した遷移に時間制限があるか否かを判定し（ステップＳ６）、時間制限がない場合には、ステップＳ９へ進む。一方、時間制限がある場合には、状態判定部３６は、現在状態（ｂ）の最終更新時刻に制限時間を加え、遷移期限時刻を算出する（ステップＳ７）。

そして、状態判定部３６は、現在時刻が遷移期限時刻を超えているか否かを判定する（ステップＳ８）。そして、状態判定部３６は、超えていない場合には、動作状況ログを、受信した現在状態（ａ）に更新し（ステップＳ９）、超えた場合には、現在状態（ｂ）をアプリエラーの状態に更新する（ステップＳ１０）。

そして、状態判定部３６は、エラー状態に遷移したか否かを判定し（ステップＳ１１）、エラー状態に遷移した場合には、エラー情報を通知する（ステップＳ１２）。ここで、「エラー状態」とは、例えば、図２に示したアプリエラー又はミドルエラーの状態である。

このように、状態判定部３６は、アプリ２１の状態遷移が状態遷移モデルの定義に従っているか否かを判定することによって、アプリ２１の動作状況が正常か否かを判定することができる。

次に、タイマー起動時の状態判定部３６による処理のフローについて説明する。図１５は、タイマー起動時の状態判定部３６による処理のフローを示すフローチャートである。図１５に示すように、状態判定部３６は、タイマーにより定期的に起動される（ステップＳ２１）。

そして、状態判定部３６は、動作状況ログから１つアプリ２１の現在状態（ｂ）を取得する（ステップＳ２２）。そして、状態判定部３６は、デバイス２に対応する種別を特定し、特定した種別に対応する状態遷移モデルのＸＭＬ記述を取得する（ステップＳ２３）。

そして、状態判定部３６は、状態遷移モデルのＸＭＬ記述から、遷移元（ｆｒｏｍ）が現在状態（ｂ）と一致する遷移（Ｔｒａｎｓ）を取得する（ステップＳ２４）。そして、状態判定部３６は、一致した遷移に時間制限があるか否かを判定し（ステップＳ２５）、時間制限がない場合には、ステップＳ３０へ進む。一方、時間制限がある場合には、状態判定部３６は、現在状態（ｂ）の最終更新時刻に制限時間を加え、遷移期限時刻を算出する（ステップＳ２６）。

そして、状態判定部３６は、現在時刻が遷移期限時刻を超えているか否かを判定する（ステップＳ２７）。そして、状態判定部３６は、超えていない場合には、ステップＳ３０へ進み、超えた場合には、現在状態（ｂ）をアプリエラーの状態に更新し（ステップＳ２８）、エラー情報を通知する（ステップＳ２９）。

そして、状態判定部３６は、動作状況ログに未処理のデバイス情報があるか否かを判定し（ステップＳ３０）、ある場合には、ステップＳ２２に戻り、ない場合には、処理を終了する。

このように、状態判定部３６は、定期的にアプリ２１の状態遷移の時間制限をチェックすることで、アプリ２１が正しく動作しているか否かを判定することができる。

上述してきたように、実施例では、状態遷移モデル記憶部３１がアプリ２１の状態遷移モデルを記憶し、ログ記憶部３２がアプリ２１の動作状況ログを記憶する。そして、状態判定部３６が、デバイス２から状態通知を受信すると、動作状況ログからアプリ２１の現在状態（ｂ）を特定し、状態通知からアプリの現在状態（ａ）を特定する。また、状態判定部３６は、状態通知からアプリ２１の状態遷移モデルを特定する。そして、状態判定部３６は、現在状態（ｂ）から現在状態（ａ）への遷移に付加されている遷移条件を満たさない場合に、アプリ２１の動作が正常でないと判定する。したがって、監視装置３は、デバイス２で動作するアプリ２１の動作を監視することができる。

また、実施例では、遷移条件に時間制限を含むこととしたので、監視装置３は、制限時間のある動作をアプリ２１が正しく行っているかを監視することができる。

また、実施例では、統計モデル構築部３９が動作状況ログを用いて統計モデルを構築して統計モデル記憶部３４に格納し、状態可視化部４１が、統計モデルを可視化して表示装置に表示する。したがって、監視装置３は、複数のアプリ２１の全体的把握に有用な情報を提供することができる。

また、実施例では、統計モデル構築部３９は、統計モデルが定義されたエラー状態になっている場合に、緊急通知を表示装置に表示するので、例えば、エラーが特定の場所で同時多発している等の状況をユーザに認識させることができる。

なお、実施例では、監視装置３について説明したが、監視装置３が有する構成をソフトウェアによって実現することで、同様の機能を有する監視プログラムを得ることができる。そこで、監視プログラムを実行するコンピュータについて説明する。

図１６は、実施例に係る監視プログラムを実行するコンピュータのハードウェア構成を示す図である。図１６に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メインメモリ５１は、プログラムやプログラムの実行途中結果などを記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行される監視プログラムは、ＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読み出されてコンピュータ５０にインストールされる。あるいは、監視プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた監視プログラムは、ＨＤＤ５４に記憶され、メインメモリ５１に読み出されてＣＰＵ５２によって実行される。

また、実施例では、デバイス２で１つのアプリ２１が動作する場合について説明したが、本発明はこれに限定されるものではなく、デバイス２で複数のアプリ２１が動作する場合にも同様に適用することができる。デバイス２で複数のアプリ２１が動作する場合に、アプリ２１及びログ収集プログラム２２は、アプリ２１を識別するためのアプリＩＤも状態通知に含めて監視装置３に送信する。監視装置３は、アプリＩＤからアプリ２１の種別を判定してログ記憶部３２の種別に書き込む。

１ ＩｏＴシステム
２ デバイス
３ 監視装置
２１ アプリ（ＩｏＴ分散アプリ）
２２ ログ収集プログラム
３１ 状態遷移モデル記憶部
３２ ログ記憶部
３３ 通知設定情報記憶部
３４ 統計モデル記憶部
３５ 通信部
３６ 状態判定部
３６ａ 第１特定部
３６ｂ 第２特定部
３６ｃ 第３特定部
３６ｄ 判定部
３６ｅ 通知部
３７ 通知設定管理部
３８ 時間監視部
３９ 統計モデル構築部
４０ 状態遷移判定部
４１ 状態可視化部
４６，４８ アプリ種別テンプレート部分
４７，４９ アプリ固有拡張部分
５０ コンピュータ
５１ メインメモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (8)

1. 複数のデバイスから送信された状態通知に含まれるアプリの状態に基づいて各デバイスで動作するアプリの状態を記憶するログ記憶部と、
   前記複数のデバイスのうちの１つである第１デバイスから状態通知を受信すると、受信した状態通知に基づいて前記ログ記憶部を検索して該第１デバイスで動作する第１アプリの第１状態を特定する第１特定部と、
   前記受信した状態通知に含まれるアプリの状態を前記第１アプリの第２状態として特定する第２特定部と、
   前記受信した状態通知に基づいて前記第１アプリに対応づけられた状態遷移モデルを特定する第３特定部と、
   前記第１状態から前記第２状態への遷移が前記状態遷移モデルで定義された状態遷移に関する所定の条件を満たすか否かを判定する判定部と、
   前記判定部により前記所定の条件を満たさないと判定された場合に、前記第１アプリにエラーが発生したことを通知する通知部と
   を有することを特徴とする監視装置。
2. 前記所定の条件は、前記第１状態から前記第２状態への時間制限であることを特徴とする請求項１に記載の監視装置。
3. 前記ログ記憶部が記憶するアプリの状態に基づいて、前記複数のデバイスで動作する複数のアプリの状態を集計する集計部と、
   前記集計部により集計された複数のアプリの状態を表示する表示部と
   をさらに有することを特徴とする請求項１に記載の監視装置。
4. 前記集計部は、集計結果がエラー状態として定義されている場合に、緊急通知を行うことを特徴とする請求項３に記載の監視装置。
5. 各デバイスでは１つのアプリが動作し、前記状態通知はデバイスで動作するアプリの状態を含むことを特徴とする請求項１〜４のいずれか１つに記載の監視装置。
6. 各デバイスでは複数のアプリが動作し、前記状態通知はアプリを識別する識別子と該アプリの状態を含むことを特徴とする請求項１〜４のいずれか１つに記載の監視装置。
7. コンピュータが、
   複数のデバイスから送信された状態通知に含まれるアプリの状態に基づいて各デバイスで動作するアプリの状態をログ記憶部に記憶し、
   前記複数のデバイスのうちの１つである第１デバイスから状態通知を受信すると、受信した状態通知に基づいて前記ログ記憶部を検索して該第１デバイスで動作する第１アプリの第１状態を特定し、
   前記受信した状態通知に含まれるアプリの状態を前記第１アプリの第２状態として特定し、
   前記受信した状態通知に基づいて前記第１アプリに対応づけられた状態遷移モデルを特定し、
   前記第１状態から前記第２状態への遷移が前記状態遷移モデルで定義された状態遷移に関する所定の条件を満たすか否かを判定し、
   前記所定の条件を満たさないと判定した場合に、前記第１アプリにエラーが発生したことを通知する
   処理を実行することを特徴とする監視方法。
8. コンピュータに、
   複数のデバイスから送信された状態通知に含まれるアプリの状態に基づいて各デバイスで動作するアプリの状態をログ記憶部に記憶し、
   前記複数のデバイスのうちの１つである第１デバイスから状態通知を受信すると、受信した状態通知に基づいて前記ログ記憶部を検索して該第１デバイスで動作する第１アプリの第１状態を特定し、
   前記受信した状態通知に含まれるアプリの状態を前記第１アプリの第２状態として特定し、
   前記受信した状態通知に基づいて前記第１アプリに対応づけられた状態遷移モデルを特定し、
   前記第１状態から前記第２状態への遷移が前記状態遷移モデルで定義された状態遷移に関する所定の条件を満たすか否かを判定し、
   前記所定の条件を満たさないと判定した場合に、前記第１アプリにエラーが発生したことを通知する
   処理を実行させることを特徴とする監視プログラム。

Images