JP2020140317A

JP2020140317A - 電子機器、制御方法、プログラム、及び学習済みモデル

Info

Publication number: JP2020140317A
Application number: JP2019033833A
Authority: JP
Inventors: 博行隅; Hiroyuki Sumi; 典利吉山; Noritoshi Yoshiyama
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2019-02-27
Filing date: 2019-02-27
Publication date: 2020-09-03
Anticipated expiration: 2039-02-27
Also published as: JP6792656B2

Abstract

【課題】機器の異常を精度よく検出する電子機器、制御方法、プログラム、及び学習済みモデルを提供する。【解決手段】自己診断システム１において、電子機器１０は、プログラムに基づいて処理を実行するプロセッサと、処理におけるスレッドごとのプロセッサの使用率を示す情報を取得する取得部とを備える。学習装置３０は、取得したデータセットを用いて機械学習を行う異常検出モデルを生成する。異常検出部１１２は、取得部が取得したスレッドごとのプロセッサの使用率に基づいて機械学習された異常検出モデルを用いて、異常を検出する。【選択図】図１

Description

本発明は、電子機器、制御方法、プログラム、及び学習済みモデルに関する。

ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）などのプロセッサを搭載して処理を実行する電子機器では、実行中の処理が原因となってパフォーマンスの低下などの問題が発生することがある（例えば、特許文献１参照）。

特開２０１５−１８４９０９号公報

しかしながら、電子機器が異常な状態であるか否かをハードウェアの動作状態などから検出しようとしても、例えばＣＰＵの使用率が高くても単に処理量が多いだけで正常な動作の場合もあるため、精度よく検出することが難しかった。

本発明は、上記した事情に鑑みてなされたもので、異常を精度よく検出することができる電子機器、制御方法、プログラム、及び学習済みモデルを提供することを目的の一つとする。

本発明は上記の課題を解決するためになされたものであり、本発明の第１態様に係る電子機器は、プログラムに基づいて処理を実行するプロセッサと、前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得部と、前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出部と、を備える。

上記電子機器において、前記異常検出部は、前記スレッドごとの前記プロセッサの使用率と異常の有無に関する情報とに基づいて機械学習された学習済みモデルを用いて、前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を検出してもよい。

上記電子機器において、前記異常検出部は、前記プロセッサを使用しているスレッドの合計数に対する特定の前記プロセッサの使用率であるスレッドの数の割合に基づいて機械学習された学習済みモデルを用いて、前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を検出してもよい。

上記電子機器において、前記取得部は、前記プロセッサを含むシステムの状態が予め設定された複数のそれぞれの状態となるタイミングで、前記スレッドごとの前記プロセッサの使用率を取得し、前記異常検出部は、前記タイミングのそれぞれで前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を、前記タイミングのそれぞれに対応する学習済みモデルを用いて検出してもよい。

また、本発明の第２態様に係るプログラムに基づいて処理を実行するプロセッサを備える電子機器における制御方法は、取得部が、前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得ステップと、異常検出部が、前記取得ステップより取得された前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出ステップと、を有する。

また、本発明の第３態様に係るプログラムに基づいて処理を実行するプロセッサを備える電子機器としてのコンピュータに、前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得ステップと、取得された前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出ステップと、を実行させる。

また、本発明の第４態様に係るプログラムに基づいて処理を実行するプロセッサを備えた電子機器の異常を検出するための学習済みモデルは、前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報と異常の有無に関する情報とに基づいて、前記異常を検出するよう、コンピュータを機能させる。

本発明の上記態様によれば、機器の異常を精度よく検出することができる。

第１の実施形態に係る自己診断システムの概要を説明するシステム図。第１の実施形態に係る電子機器のハードウェアの構成例を示すブロック図。第１の実施形態に係る電子機器の機能構成の一例を示すブロック図。第１の実施形態に係るクラスタリングの結果の参考例を示す図。第１の実施形態に係る自己診断処理の一例を示すフローチャート。第２の実施形態に係るシステムの状態情報の取得タイミング例を説明する図。第２の実施形態に係るシステムの状態情報のデータ例を示す図。第２の実施形態に係るシステムの状態情報のデータ例を示す図。第２の実施形態に係るシステムの状態情報のデータ例を示す図。スレッドごとのＣＰＵ使用率の実験結果の一例を示す図。第２の実施形態に係る異常検出モデルで用いるデータセットを説明する図。第２の実施形態に係るシステムの状態のカテゴリの例を示す図。

以下、図面を参照しながら本発明の実施形態について詳しく説明する。

［第１の実施形態］
本発明の第１の実施形態について説明する。
（システムの概要）
まず、本実施形態に係る自己診断システムの概要について説明する。図１は、本実施形態に係る自己診断システム１の概要を説明するシステム図である。図示する自己診断システム１は、電子機器１０と、電子機器１０と通信接続されるクラウド（クラウドコンピューティング）上のストレージであるデータベース２０と、データベース２０に蓄積されるデータに基づいて機械学習した学習済みモデルを提供する学習装置３０（サーバ装置）とを備えている。電子機器１０は、例えば、ラップトップ型のパーソナルコンピュータであるが、デスクトップ型やタブレット型などのパーソナルコンピュータであってもよい。電子機器１０は、自身のパフォーマンスの低下などの異常（問題）を検出し、更にその原因を検出する。

電子機器１０は、電子機器１０自身のシステムの状態に関する状態情報（Ｒａｗデータ）を収集し、収集したシステムの状態情報に基づいて、自身の異常を検出する。以下では特に明示しない限り、システムとは、電子機器１０が備えるハードウェアやシステムファームウェアなどを用いたシステムのことを指し、自己診断システム１とは異なる概念とする。システムの状態情報には、例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）に関する情報（ＣＰＵ使用率、ＣＰＵの温度など）、ＧＰＵ（ＧｒａｐｈｉｃＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）に関する情報（ＧＰＵ使用率など）、システムの動作状態に基づく情報（ＢＳＯＤ：ＢｌｕｅＳｃｒｅｅｎｏｆＤｅａｔｈ、ハングアップなど）、バッテリに関する情報（放電カーブ、満充電、残量少、充電開始時間、放電開始時間など）、ファンの回転速度の情報などが含まれる。電子機器１０の異常検出部１１２は、システムの状態情報の中から異常値を検出し、電子機器１０の異常を検出する。電子機器１０の異常とは、例えば、「バッテリ寿命が短い」、「パフォーマンス低下（処理が遅い）」、「頻繁にシステムがハングアップする」などのように電子機器１０で問題や故障などが生じている状況や状態が含まれる。

また、電子機器１０は、異常が検出された場合に、当該異常を分類するための分類情報（Ｒａｗデータ）を収集し、検出された異常を分類情報に基づいて分類（クラスタリング）することにより異常の原因を検出する。異常を分類するための分類情報には、例えば、製品名、動作中のアプリケーション（以下、単にアプリと称する）のリスト、サービスのリスト、ドライバのリストや、ＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔＯｕｔｐｕｔＳｙｓｔｅｍ）のバージョンの情報などが含まれる。電子機器１０の原因検出部１１４は、異常検出部１１２により検出された異常を、収集した分類情報を用いて分類（クラスタリング）することにより異常の原因を検出する。異常の原因としては、例えば、「アプリＡのパフォーマンスが非常に低い」、「アプリＥのパフォーマンスに重篤な問題がある」といったように、異常の原因となっているアプリ、サービス、ドライバなどが原因として特定される。

ここで、異常検出部１１２及び原因検出部１１４は、それぞれＡＩ（ＡｒｔｉｆｉｃｉａｌＩｎｔｅｌｌｉｇｅｎｃｅ）エンジンを備えている。異常検出部１１２は、システムの状態情報に基づくデータセットを用いて機械学習された学習済みモデル（以下、「異常検出モデル」と称する）を用いて異常を検出するローカルＡＩとして機能する。原因検出部１１４は、検出された異常内容を示す情報と分類情報とに基づいて機械学習された学習済みモデル（以下、「原因検出モデル」と称する）を用いて異常の原因を検出するローカルＡＩとして機能する。

このように、電子機器１０は、異常を検出するためのＡＩ（異常検出部１１２）と異常の原因を検出するためのＡＩ（原因検出部１１４）との２つのＡＩを用いて自己診断を行い、異常の原因を検出する。電子機器１０は、通常は異常を検出するためのシステムの状態情報を収集し、異常の原因を検出するための分類情報については収集にかなりの処理負荷がかかるため、異常検出部１１２により異常が検出された場合のみ収集する。これにより、電子機器１０は、正常時には自己診断処理に要する負荷を抑制することができるため、バッテリ寿命への影響を低減できるとともに、通常の処理を妨げないようにすることができる。

なお、原因検出部１１４は、検出された異常の分類ができなかった場合、分類できない異常データ（未分類の異常データ）を、データ提供部１１５を介してクラウド上のデータベース２０（ＤＢ）へ送信する。データベース２０は、電子機器１０から送信された未分類の異常データを格納し蓄積する。なお、データベース２０は、複数のユーザのそれぞれが使用する複数の電子機器１０から送信された未分類の異常データを格納し蓄積してもよい。未分類の異常データには、異常の内容と収集した分類情報とが含まれる。学習装置３０は、データベース２０に格納されている未分類の異常データに対してクラスタ分析及びデータ分析により機械学習を行うことにより原因検出モデルを生成または更新し、原因検出モデルとその異常の解決策を提供する。学習装置３０は、予め設定されたタイミングまたは原因検出モデルを更新したタイミングなどで、電子機器１０へ原因検出モデルを送信し、電子機器１０で使用する原因検出モデルを更新する。これにより、分類できなかった異常と同様の異常が次に生じた場合には分離できるようになり原因を検出可能な異常の症状が増える。

また、電子機器１０は、原因検出部１１４による検出結果に基づく情報を表示部１２に表示することにより、異常に関する情報をユーザに通知する。電子機器１０は、異常に関する情報として、例えば、異常の内容及び異常の原因に関する情報（例えば、「アプリＡがパフォーマンスの問題を引き起こしています」）を表示する。また、電子機器１０は、異常に関する情報として、その異常の解決策や対応策を示す情報を表示してもよい。図示する「ＹＥＳ」が表示されているボタンＢ１２１は、異常に関する詳細情報表示するための操作子として表示されている。ボタンＢ１２１に対する操作がされると、電子機器１０は、異常の内容や原因の詳細を示す情報、異常の原因に対する対処方法（解決策や対応策など）を示す情報などを表示してもよい。例えば、対処方法としては、異常の原因となっているアプリのアップデートまたは再インストールや、システムの再起動などをユーザに依頼する内容が表示される。

次に、電子機器１０の構成について詳しく説明する。
（電子機器のハードウェア構成）
図２は、本実施形態に係る電子機器１０のハードウェアの構成例を示す概略ブロック図である。電子機器１０は、通信部１１、表示部１２、スピーカ１３、入力部１４、電源部１５、温度センサ１７、ファン１６、ＥＣ（ＥｍｂｅｄｄｅｄＣｏｎｔｒｏｌｌｅｒ）１８、記憶部１９、及びシステム処理部１００を含んで構成される。システム処理部１００は、ＣＰＵ１０１、ＧＰＵ１０２、メモリコントローラ１０３、Ｉ／Ｏ（Ｉｎｐｕｔ−Ｏｕｔｐｕｔ）コントローラ１０４、及びシステムメモリ１０５を含んで構成され、オペレーティングシステム（ＯＳ：ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）によるシステム処理によって、ＯＳ上で各種アプリのプログラムの処理が実行可能である。ＣＰＵ１０１とＧＰＵ１０２をプロセッサと総称することがある。

通信部１１は、無線または有線による通信ネットワークを介して他の機器と通信可能に接続し、各種のデータの送信および受信を行う。例えば、通信部１１は、イーサネット（登録商標）等の有線ＬＡＮインターフェースやＷｉ−Ｆｉ（登録商標）等の無線ＬＡＮインターフェース等を含んで構成されている。なお、通信部１１は、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）インターフェースやＢｌｕｅｔｏｏｔｈ（登録商標）インターフェースを含んで構成されてもよい。

表示部１２は、映像、画像、テキスト等を表示するディスプレイであり、例えば、液晶ディスプレイパネル、有機ＥＬディスプレイパネルなどを含んで構成される。スピーカ１３は、電子音や音声などを出力する。

入力部１４は、ユーザの入力を受け付ける入力部であり、例えばキーボードやタッチパッドなどの入力デバイスを含んで構成されている。入力部１４は、キーボード、タッチパッドなどに対する操作を受け付けることに応じて、操作内容を示す操作信号をＥＣ１８へ出力する。なお、入力部１４は、表示部１２の表示画面に対する操作を受け付けるタッチパネルを含んで構成されてもよい。

電源部１５は、電子機器１０の各部の動作状態に応じて各部へ電源系統を介して電力を供給する。電源部１５は、ＤＣ（ＤｉｒｅｃｔＣｕｒｒｅｎｔ）／ＤＣコンバータを備える。ＤＣ／ＤＣコンバータは、ＡＣ（ＡｌｔｅｒｎａｔｅＣｕｒｒｅｎｔ）／ＤＣアダプタ又はバッテリ１５１から供給される直流電力の電圧を、各部で要求される電圧に変換する。ＤＣ／ＤＣコンバータで電圧が変換された電力が各電源系統を介して各部へ供給される。例えば、電源部１５は、ＥＣ１８から入力される各部の動作状態に応じて制御信号に基づいて各電源系統を介して各部に電力を供給する。

温度センサ１７は、電子機器１０の筐体内部に一又は複数設けられ、環境温度を検出する。例えば、温度センサ１７は、ＣＰＵ１０１の近傍やバッテリ１５１の近傍など温度が上昇しやすい箇所に設けられている。
ファン１６は、電子機器１０の内部の上昇した温度を低下させるための冷却用として設けられている。

ＥＣ１８は、ＣＰＵ１０１の処理に関わらず、各種デバイス（周辺装置やセンサ等）の監視及び制御を行うマイクロコンピュータが組み込まれた組み込みコントローラであり、バッテリの管理、電源管理、キーボードコントローラなどの機能を有する。例えば、ＥＣ１８は、入力部１４と、電源部１５と、ファン１６と、温度センサ１７とに接続されている。ＥＣ１８は、入力部１４から操作信号を取得する。また、ＥＣ１８は、不図示の電源ボタンに対する操作に応じて起動信号を生成する。また、ＥＣ１８は、各部への給電のＯＮ／ＯＦＦの指示を電源部１５に対して行うとともに、バッテリに関する情報（放電カーブ、満充電、残量少、充電開始時間、放電開始時間など）を電源部１５から取得する。また、ＥＣ１８は、温度センサ１７の検出結果を取得し、検出結果（温度）に応じて、ファン１６のＯＮ／ＯＦＦ、およびＯＮ時の回転速度などを制御する。ＥＣ１８とＣＰＵ１０１とは通信を行うことにより、各種情報や各動作状態などを共有する。

記憶部１９は、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）などの記憶媒体を含んで構成される。記憶部１９には、ＢＩＯＳ、ＯＳ、デバイスドライバ、アプリなどの各種のプログラムや、その他、プログラムの処理に必要なデータ、プログラムの処理により取得した各種のデータなどが記憶される。

ＣＰＵ１０１は、ＢＩＯＳやＯＳによるシステム処理により動作状態を制御する。システムの動作状態として少なくとも通常動作状態（パワーオン状態）と待機状態（アイドル状態）との間を遷移可能である。待機状態には、スタンバイ状態、スリープ状態、ハイバネーション状態およびパワーオフ状態が含まれる。

スタンバイ状態は、プロセッサの処理能力を通常動作状態よりも低くし、動作中のシステムメモリ１０５の内容を保持しながら通信部１１、表示部１２、スピーカ１３、及び記憶部１９など周辺デバイスの消費電力を通常動作状態よりも少なくする動作状態である。
スリープ状態は、システムメモリ１０５とＥＣ１８とその配下にあるデバイス以外のデバイスへの給電を停止し、プロセッサによるプログラムの実行を伴わない動作モードである。
ハイバネーション状態は、スリープ状態においてプロセッサから即座にアクセス可能とする補助記憶装置にシステムメモリ１０５に記憶していた情報を全て退避させ、その後、システムメモリ１０５への給電をさらに停止するモードである。従って、ハイバネーション状態から起動処理を開始する際、ＣＰＵ１０１は、補助記憶装置に退避された情報をシステムメモリ１０５に記憶する。
パワーオフ状態は、ＥＣ１８とその配下にあるデバイス以外のデバイスへの給電を停止した状態である。

例えば、ＣＰＵ１０１は、動作状態が待機状態であって、ＥＣ１８から起動信号が入力された場合、待機状態から通常動作状態に遷移させる。例えば、動作状態がスリープ状態、ハイバネーション状態またはパワーオフ状態であるとき、電源部１５から電力の供給を受け、かつＥＣ１８から起動信号が入力されると、ＣＰＵ１０１は、起動処理を開始する。ＣＰＵ１０１は、起動処理において、システムメモリ１０５、記憶部１９などの最小限のデバイスの検出と初期化を行う（プリブート）。ＣＰＵ１０１は、記憶部１９からＢＩＯＳをシステムメモリ１０５にロードし、通信部１１、表示部１２などその他のデバイスの検出と初期化を行う（ポスト処理）。初期化には、初期パラメータの設定などの処理が含まれる。なお、スリープ状態から通常動作状態への遷移（レジューム）においては、ポスト処理の一部が省略されることがある。ＣＰＵ１０１は、起動処理が完了した後、ＯＳによるシステム処理の実行を開始する（起動）。

また、ＣＰＵ１０１は、ＯＳが起動した後、インストールされているアプリのプログラムを実行することにより、当該アプリの機能を実現する。例えば、図１を参照して説明した自己診断処理は、当該自己診断を行うための自己診断アプリとして提供され、自己診断アプリのプログラムを実行することにより、その機能を実現する。

ＧＰＵ１０２は、ＣＰＵ１０１の制御に基づいて画像処理を実行して表示データを生成する。ＧＰＵ１０２は、生成した表示データを表示部１２に出力する。なお、ＣＰＵ１０１とＧＰＵ１０２は、一体化して１個のコアとして形成されてもよいし、個々のコアとして形成されたＣＰＵ１０１とＧＰＵ１０２の相互間で負荷が分担されてもよい。プロセッサの数は、１個に限られず、複数個であってもよい。

メモリコントローラ１０３は、ＣＰＵ１０１とＧＰＵ１０２によるシステムメモリ１０５、記憶部１９などからのデータの読出し、書込みを制御する。
Ｉ／Ｏコントローラ１０４は、通信部１１、表示部１２、スピーカ１３、及びＥＣ１８とのデータの入力または出力を制御する。
システムメモリ１０５は、ＣＰＵ１０１が実行するプログラムの読み込み領域ならびに処理データを書き込む作業領域として用いられる。

次に、電子機器１０における自己診断処理に関する機能構成について説明する。
図３は、本実施形態に係る電子機器１０の機能構成の一例を示すブロック図である。制御部１１０は、ＣＰＵ１０１が自己診断アプリのプログラムを実行することにより実現する自己診断処理の機能構成を示している。制御部１１０は、第１取得部１１１と、異常検出部１１２と、第２取得部１１３と、原因検出部１１４と、データ提供部１１５と、検出結果出力部１１６とを備えている。また、自己診断処理に用いるデータを記憶する構成として、記憶部１９は、第１情報記憶部１９１と、第２情報記憶部１９２と、第３情報記憶部１９３と、異常検出モデル記憶部１９４と、原因検出モデル記憶部１９５と、検出結果記憶部１９６とを備えている。

第１取得部１１１は、電子機器１０のシステムの状態に関する状態情報（第１情報の一例）を取得する。例えば、第１取得部１１１は、予め設定されたタイミングで、システムの状態情報を取得し、取得した情報を取得したタイミングを示す情報と関連付けて、第１情報記憶部１９１に記憶させる。前述したように、システムの状態情報には、プロセッサ（ＣＰＵ１０１又はＧＰＵ１０２など）の使用率を示す情報、システムの動作状態に基づく情報、バッテリに関する情報、ファンの回転速度の情報などが含まれる。

異常検出部１１２は、第１取得部１１１が取得したシステムの状態情報に基づいて異常を検出する。例えば、異常検出部１１２は、異常を検出するための学習済みモデルである異常検出モデルを用いて、第１取得部１１１が取得したシステムの状態情報に対応する異常を検出する。この異常検出モデルは、以前に電子機器１０または他の電子機器で取得されたシステムの状態情報と、そのシステムの状態情報に対応する異常の有無に関する情報とに基づいて機械学習された学習済みモデルである。例えば、機械学習のアルゴリズムとしてＯｎｅＣｌａｓｓＳＶＭ（ＳｕｐｐｏｒｔＶｅｃｔｏｒＭａｃｈｉｎｅ）が用いられ、正常なシステムの状態情報を学習データとして機械学習させることで異常値との識別境界を決定し、当該識別境界を基準として異常の検出を行う。電子機器１０は、この異常検出モデルを事前に外部のサーバ装置や記憶媒体を介して取得し、異常検出モデル記憶部１９４に記憶している。なお、この機械学習は、学習装置３０で行われてもよい。また、異常検出部１１２は、異常を検出した場合、異常を示す異常情報（第２情報の一例）を生成し、第２情報記憶部１９２に記憶させる。例えば、異常検出部１１２は、検出した異常を、「バッテリ寿命が短い」、「パフォーマンス低下（処理が遅い）」、「頻繁にシステムがハングアップする」などのような予め設定されている異常内容にラベリングすることにより、異常情報を生成する。例えば、「パフォーマンス低下（処理が遅い）」は、プロセッサ（ＣＰＵ１０１又はＧＰＵ１０２など）の使用率に基づいて検出された異常情報である。また、異常情報は、システム状態でカテゴリ分けされてもよい。例えば、「パフォーマンス低下（処理が遅い）」という異常が検出された場合、異常が起きているときのシステム状態として、ＣＰＵ使用率が高い状態（ＨｉｇｈＣＰＵｕｓａｇｅ）、ＣＰＵ使用率が低い状態（ＬｏｗＣＰＵｕｓａｇｅ）、システムがアイドル状態（Ｉｄｌｅ）などにカテゴリ分けされてもよい。なお、ＣＰＵ使用率が高いか低いかの判別の閾値は、予め設定された値、または式により算出される値である。

第２取得部１１３は、異常検出部１１２により異常が検出された場合、第２情報記憶部１９２に記憶されている情報を参照して、異常検出部１１２により生成された異常情報を取得する。また、第２取得部１１３は、異常検出部１１２により異常が検出された場合、異常を分類するため分類情報（第３情報の一例）を取得する。分類情報には、電子機器１０のシステムを用いて実行している処理に関する情報が含まれる。例えば前述したように、分類情報には、製品名、動作中のアプリのリスト、サービスのリスト、ドライバのリストや、ＢＩＯＳのバージョンの情報などが含まれる。

原因検出部１１４は、第２取得部１１３が取得した異常情報と分類情報とに基づいて異常の原因を検出する。例えば、原因検出部１１４は、第２取得部１１３が取得した異常情報と分類情報と、異常の原因を検出するための原因検出モデルとを用いて、異常をクラスタリングすることにより原因を検出する。この原因検出モデルは、以前に電子機器１０または他の電子機器で生じた異常を、その異常が乗じたときの分類情報に基づいてクラスタ分析して分類することにより機械学習された学習済みモデルである。機械学習は、例えば、学習装置３０で行われる。電子機器１０は、学習装置３０から原因検出モデルを取得し、原因検出モデル記憶部１９５に記憶している。

ここで、学習装置３０で行われる原因検出モデルの機械学習の例について説明する。学習装置３０は、電子機器１０または他の電子機器で収集された複数の異常についての異常情報と分類情報とに基づいて、各異常を分類情報を用いてクラスタリングする。
図４は、クラスタリングの結果の参考例を示す図である。図示する例は、「パフォーマンス低下（処理が遅い）」の異常を、分類情報のアプリのリストを用いてクラスタリングした結果を示している。横軸はアプリを示し、縦軸は異常の件数を示している。図４（Ａ）、（Ｂ）、（Ｃ）のそれぞれは、カテゴリが、ＣＰＵ使用率が高い状態（ＨｉｇｈＣＰＵｕｓａｇｅ）、ＣＰＵ使用率が低い状態（ＬｏｗＣＰＵｕｓａｇｅ）、システムがアイドル状態（Ｉｄｌｅ）のそれぞれのときのクラスタリング結果の一例（イメージ）を示している。

図４（Ａ）に示す例では、アプリＡに分類された件数が最も多いため、パフォーマンスの低下にアプリＡが起因している可能性が高い。そのため、例えばアプリＡが異常の原因として推定される。図４（Ｂ）に示す例では、アプリＡ及びアプリＤに分類された件数が最も多いため、パフォーマンスの低下にアプリＡまたはアプリＤが起因している可能性が高い。そのため、例えばアプリＡまたはアプリＤが異常の原因として推定される。図４（Ｃ）に示す例では、アプリＪに分類された件数が最も多いため、パフォーマンスの低下にアプリＪが起因している可能性が高い。そのため、例えばアプリＪが異常の原因として推定される。学習装置３０は、上述したようなクラスタリング（クラスタ分析）を行うことにより、異常の内容及びカテゴリごとに機械学習を行い、異常の内容及びカテゴリごとに原因検出モデルを生成する。

電子機器１０の原因検出部１１４は、学習装置３０で生成された原因検出モデルを取得し、異常検出部１１２により検出された異常の内容及びカテゴリごとに、それぞれ対応する原因検出モデルを用いて異常の原因を検出する。例えば、原因検出部１１４は、図４（Ａ）に示すクラスタリング結果に基づく原因検出モデルを用いて同様の異常をクラスタリングした場合、その異常がアプリＡに分類され、アプリＡが異常の原因として検出される。

なお、原因検出部１１４は、第２取得部１１３が取得した異常情報と分類情報とに基づいて異常の原因を検出できない場合（即ち、異常を分類できない場合）、第２取得部１１３が取得した異常情報及び分類情報を未分類の異常データとして、通信接続される学習装置３０で利用可能なデータベース２０へデータ提供部１１５を介して送信する。

学習装置３０は、データベース２０から未分類の異常データを取得し、取得した未分類の異常データに基づいて機械学習を行うことにより、原因検出モデルを更新する。例えば、データ分析を行う技術者は、未分類の異常データに対してデータ分析を行い、異常の有無の判断と、異常であると判断される場合には、その異常の原因、異常の解決策などをみつけ、学習装置３０へ入力する。学習装置３０は、入力された異常の原因、異常の解決策などのデータを、未分類の異常データをクラスタリングしたときの期待値として、機械学習し、原因検出モデルを更新する。また、原因検出部１１４は、送信した未分類の異常データに基づいて学習装置３０で機械学習されて更新された原因検出モデルを取得する。以降、原因検出部１１４は、更新された原因検出モデルを用いて異常の原因を検出する。

データ提供部１１５は、原因検出部１１４で異常の原因を検出できなかった異常についての異常情報及び分類情報を通信部１１を介してデータベース２０へ送信する。

検出結果出力部１１６は、原因検出部１１４による検出結果に基づく情報を出力する。検出結果に基づく情報とは、異常の原因を示す情報、または異常の原因に対する対処方法を示す情報である。例えば、検出結果出力部１１６は、原因検出部１１４による検出結果に基づいて、異常の原因を示す情報を表示部１２に表示させる。また、検出結果出力部１１６は、原因検出部１１４による検出結果に基づいて、異常の原因に対する対処方法を示す情報を表示部１２に表示させてもよい。なお、出力方法としては、表示部１２への」表示に代えて、または加えてスピーカ１３から音声として出力させてもよい。また、検出結果出力部１１６は、検出履歴情報として、検出結果に基づく情報を検出結果記憶部１９６に記憶させる。

次に、電子機器１０において制御部１１０が実行する自己診断処理の動作について説明する。図５は、本実施形態に係る自己診断処理の一例を示すフローチャートである。
（ステップＳ１０１）制御部１１０は、予め設定されたタイミングで、電子機器１０のシステムの状態情報を取得し、取得した情報を取得したタイミングを示す情報と関連付けて、第１情報記憶部１９１に記憶させる。そして、ステップＳ１０３の処理に進む。

（ステップＳ１０３）制御部１１０は、第１情報記憶部１９１に記憶された情報を参照し、取得したシステムの状態情報に基づいて異常を検出する。例えば、異常検出部１１２は、第２情報記憶部１９２に記憶されている異常検出モデルを用いて、第１取得部１１１が取得したシステムの状態情報に対応する異常を検出する。そして、ステップＳ１０５の処理に進む。

（ステップＳ１０５）制御部１１０は、異常を検出したか否かを判定する。制御部１１０は、異常を検出したと判定した場合（ＹＥＳ）、ステップＳ１０７の処理に進む。一方、制御部１１０は、異常を検出しないと判定した場合（ＮＯ）、ステップＳ１０１の処理に戻る。

（ステップＳ１０７）制御部１１０は、異常情報を生成し、第２情報記憶部１９２に記憶させる。例えば、制御部１１０は、検出した異常を予め設定されている異常内容にラベリングすることにより、異常情報を生成する。そして、ステップＳ１０９の処理に進む。

（ステップＳ１０９）制御部１１０は、第２情報記憶部１９２に記憶されている情報を参照して、異常検出部１１２により生成された異常情報を取得する。また、第２取得部１１３は、異常検出部１１２により異常が検出された場合、異常を分類するため分類情報を取得する。そして、ステップＳ１１１の処理に進む。

（ステップＳ１１１）制御部１１０は、取得した異常情報と分類情報と、原因検出モデル記憶部１９５に記憶されている原因検出モデルとを用いて、異常を分類（クラスタリング）することにより原因を検出する。そして、ステップＳ１１３の処理に進む。

（ステップＳ１１３）制御部１１０は、異常の原因を検出したか否かを判定する。制御部１１０は、異常の原因を検出したと判定した場合（ＹＥＳ）、ステップＳ１１５の処理に進む。一方、制御部１１０は、異常の原因を検出できないと判定した場合（ＹＥＳ）、ステップＳ１１７の処理に進む。

（ステップＳ１１５）制御部１１０は、異常の原因の検出結果に基づく情報を出力する。例えば、制御部１１０は、異常の原因を示す情報、または異常の原因に対する対処方法を示す情報などを表示部１２に表示させる。

（ステップＳ１１７）制御部１１０は、異常の原因を検出できなかった異常情報及び分類情報を、データ提供部１１５を介してクラウド上のデータベース２０へ送信する。

以上説明したように、本実施形態に係る電子機器１０は、第１取得部１１１と、異常検出部１１２と、第２取得部１１３と、原因検出部１１４と、検出結果出力部１１６（出力部の一例）とを備えている。第１取得部１１１は、システムの状態に関する第１情報（例えば、システムの状態情報）を取得する。異常検出部１１２は、第１取得部１１１が取得したシステムの状態情報に基づいて異常を検出する。第２取得部１１３は、異常検出部１１２により異常が検出された場合、異常を示す第２情報（例えば、異常情報）と異常の原因を検出するための第３情報（例えば、分類情報）とを取得する。原因検出部１１４は、第２取得部１１３が取得した第２情報と第３情報とに基づいて異常の原因を検出する。検出結果出力部１１６は、原因検出部１１４による検出結果に基づく情報を出力する。

これにより、電子機器１０は、異常を検出したときのみ、異常の原因を検出するための情報を収集するため、異常検出処理に要する負荷を抑制することができ、バッテリ寿命への影響を低減できるとともに、通常の処理を妨げないようにすることができる。よって、電子機器１０は、なるべく処理負荷をかけずに電子機器１０の異常及び異常の原因を検出することができる。また、電子機器１０は、電子機器１０の異常及び異常の原因を自己診断し、ユーザに通知することができる。

例えば、原因検出部１１４は、第２取得部１１３が取得した異常情報と分類情報とに基づいて異常を分類することにより、異常の原因を検出する。これにより、電子機器１０は、電子機器１０で生じた異常を原因ごとに分類することにより、異常の原因を検出することができる。

例えば、第１取得部１１１が取得したシステムの状態情報にはＣＰＵ使用率を示す情報が含まれる。第２取得部１１３は、異常情報として、ＣＰＵ使用率に基づいて検出された異常を示す情報を取得する。そして、原因検出部１１４は、ＣＰＵ使用率に基づいて検出された異常を分類情報に基づいて分類することにより、異常の原因を検出する。これにより、電子機器１０は、ＣＰＵ使用率に基づいて異常を検出するとともに、その異常の原因を検出することができる。

一例として、原因検出部１１４は、異常情報と分類情報とに基づいて異常を分類することにより機械学習された異常検出モデル（学習済みモデルの一例）を用いて、第２取得部１１３が取得した異常情報と分類情報とに対応する異常の原因を検出する。これにより、電子機器１０は、ＡＩを用いて容易且つ精度よく異常の原因を検出することができる。

また、原因検出部１１４は、第２取得部１１３が取得した異常情報と分類情報とに基づいて異常の原因を検出できない場合、第２取得部１１３が取得した異常情報と分類情報とを、機械学習を行う学習装置３０（サーバ装置の一例）で利用可能なデータベース２０（記憶装置の一例）へ送信する。これにより、電子機器１０は、使用した異常検出モデルで異常の原因を検出できなかった場合には、学習装置３０へフィードバックするため、学習装置３０で異常検出モデルを再学習及び更新が可能なようにすることができる。

原因検出部１１４は、データベース２０へ送信した異常情報と分類情報とに基づいて学習装置３０で更新された異常検出モデルを用いて、異常の原因を検出する。これにより、電子機器１０は、学習装置３０で更新された異常検出モデルを用いることで、異常の原因の検出性能を高めることができる。

ここで、分類情報は、ＣＰＵ１０１（プロセッサの一例）を用いて実行している処理に関する情報（例えば、アプリのリスト、サービスのリスト、ドライバのリストや、ＢＩＯＳのバージョンの情報）を含む。これにより、電子機器１０は、異常の原因となっているアプリ、サービス、ドライバ、またはＢＩＯＳのバージョンなどを特定することができる。

また、異常検出部１１２は、システムの状態情報と異常の有無に関する情報とに基づいて機械学習された学習済みモデルを用いて、第１取得部１１１が取得したシステムの状態情報に対応する異常を検出する。

これにより、電子機器１０は、ＡＩを用いて容易且つ精度よく電子機器１０で生じる異常を検出することができる。また、電子機器１０は、異常を検出するＡＩと、異常の原因を検出するＡＩとの２つのＡＩを用いて自己診断することにより、異常及び異常の原因を検出するため、異常を検出したときのみ、異常の原因を検出するための情報の収集と異常の原因を検出するＡＩとを機能させることが可能である。よって、電子機器１０は、仮に１つのＡｉで異常及び異常の原因を検出するように構成するよりも、正常時には異常を検出する処理のみで済むため処理負荷を抑制することができ、バッテリ寿命への影響を低減できるとともに、通常の処理を妨げないようにすることができる。

検出結果出力部１１６は、原因検出部１１４による検出結果に基づいて、異常の原因を示す情報を出力する。これにより、電子機器１０は、異常が生じた場合に異常の原因をユーザに通知することができる。

例えば、検出結果出力部１１６は、原因検出部１１４による検出結果に基づいて、異常の原因に対する対処方法を示す情報を出力する。これにより、電子機器１０は、異常が生じた場合に対処方法をユーザに通知することができる。

［第２の実施形態］
次に、本発明の第２の実施形態について説明する。
本実施形態では、第１の実施形態で説明した異常検出処理の具体例について説明する。

まず、第１取得部１１１がシステムの状態情報を取得するタイミングについて説明する。図６は、本実施形態に係るシステムの状態情報の取得タイミングの一例を説明する図である。図示する例は、システムの状態情報の取得タイミングを示しており、縦軸がＣＰＵ使用率であり、横軸が時間軸である。第１取得部１１１は、時刻ｔ１においてトリガイベントを検出すると、当該検出タイミングに応じてシステムの状態情報を取得する。

トリガイベントは、例えば、自己診断アプリのアプリ画面（自己診断に関する各種の操作を受け付ける画面）において、「パフォーマンス測定」の開始を指示する操作ボタンへの操作がされたとき、ファン１６が回転したとき、ＣＰＵ使用率が１０秒間に「１００％／コア数」を超えたとき、或いは、所定の時間間隔（例えば、３０分）ごと、などである。例えば、「パフォーマンス測定」の開始を指示する操作ボタンへの操作がされると、第１取得部１１１は、検出開始の指示に応じてシステムの状態情報の測定を開始し、所定の期間経過後に測定を終了する。

第１取得部１１１は、時刻ｔ１から所定の期間ｔｈ（例えば３０秒間）の間はＣＰＵ使用率の測定ために、自身はＣＰＵを用いた処理は行わずに待機する。そして、時刻ｔ１から所定の期間ｔｈ（例えば３０秒間）が経過した時刻ｔ２において、第１取得部１１１は、再びシステムの状態情報を取得する。例えば、第１取得部１１１は、この時刻ｔ１と時刻ｔ２とで取得したシステムの状態情報の差分から各プロセスの各スレッドのＣＰＵ使用率などのデータを収集する。また、第１取得部１１１は、収集したシステムの状態情報をファイル（例えば、ｃｓｖファイル）にして第１情報記憶部１９１に保存する。

次に、第１取得部１１１が収集するシステムの状態情報の具体例について説明する。
図７〜９は、本実施形態に係るシステムの状態情報のデータ例を示す図である。システムの状態情報には、図７に示すように、「パフォーマンス測定」の開始時及び終了時におけるシステムの状態として、ＣＰＵ使用率（ＣｐｕＵｓａｇｅ）、ＧＰＵ使用率（ＧｐｕＵｓａｇｅ）、メモリ使用率（ＭｅｍｏｒｙＵｓａｇｅ）、通信ネットワークの接続状態（ＮｅｔｗｏｒｋＣｏｎｎｅｃｔｅｄ）などのデータが含まれる。

また、図８に示すように、パフォーマンス測定中（ＣＰＵ使用率測定中）のプロセスの合計数（ＮｕｍＯｆＰｒｏｃｅｓｓ）及びスレッドの合計数（ＮｕｍＯｆＴｈｒｅａｄ）や、パフォーマンス測定中（ＣＰＵ使用率測定中）のＣＰＵ使用率（ＣｐｕＵｓａｇｅＣｈｅｃｋ）、ＣＰＵ使用率ごとのプロセスの数（ＰｒｏＣＵ００〜ＰｒｏＣＵ５６６０）、ＣＰＵ使用率ごとのスレッドの数（ＴｈｒｅＣＵ２１２５〜ＰｒｏＣＵ１００）などのデータが含まれる。例えば、第１取得部１１１は、測定されたプロセスごとまたはスレッドごとのＣＰＵ使用率に基づいて、ＣＰＵ使用率が０％、１〜５％、６〜１０％、・・・、９６〜９９％、１００％、といったように５％刻みで、それぞれのプロセスの数またはスレッドの数のデータを生成し第１情報記憶部１９１に保存する。なお、この図８では、ＣＰＵ使用率が５％刻みの例を示したが、これに限定されるものではなく、例えば１０％刻みとしてもよい。

また、図９に示すように、プロセッサアーキテクチャ（ＰｒｏｃｅｓｓｏｒＡｒｃｈｉｔｅｃｔｕｒｅ）、論理プロセッサ数（ＮｕｍＯｆＰｒｏｃｅｓｓｏｒｓ）、メモリサイズ（ＭｅｍｏｒｙＳｉｚｅ）、システムドライブのディスクサイズ（ＤｉｓｋＳｉｚｅ）、ＯＳのバージョン（ＯＳＢｕｉｌｄＶｅｒｓｉｏｎ）などのデータが含まれる。

第１取得部１１１は、上述したシステムの状態情報の一部または全部を取得してもよい。なお、上述したシステムの状態情報は一例であって、第１取得部１１１は、これ以外の情報を取得してもよい。異常検出部１１２は、第１取得部１１１が取得したシステムの状態情報の一部または全部に基づいて、異常を検出する。

ここで、本実施形態において異常検出部１１２が異常の検出に用いるデータセットの一例を説明する。例えば、単にＣＰＵ使用率が高いといっても高負荷のアプリケーションの処理を正常に実行している場合もある。そこで、正常な処理と異常な処理とのそれぞれでスレッドごとのＣＰＵ使用率が実際にどのような傾向にあるかを調べる実験を行った。図１０は、スレッドごとのＣＰＵ使用率の実験結果の一例を示す図である。実験では、正常な処理としては、通常の作業中のときのスレッドごとのＣＰＵ使用率を測定した。また、異常な処理としては、ＣＰＵ高負荷問題を持ったアプリケーションの実行中と、無限ループのバグを持ったアプリケーションの実行中とのそれぞれについて、スレッドごとのＣＰＵ使用率を測定した。この図では、横軸をＣＰＵ使用率、縦軸をスレッドの数として、正常な処理及び異常なし処理のそれぞれについて、どの位のＣＰＵ使用率のスレッドが多いかを表している。その結果、実際には、ＣＰＵ使用率が１〜５％のスレッドの数が多い場合には正常な処理であり、異常な処理では、正常な処理のときに比較して、ＣＰＵ使用率が１０〜３０％や９０〜１００％程度のスレッドの数が相対的に多くなる傾向が実験によりわかった。このように、正常な処理と異常な処理とでは、スレッドごとのＣＰＵ使用率に差があることがわかった。そこで、異常検出部１１２は、第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に基づいて異常を検出する。一例として、異常検出部１１２は、ＣＰＵ１０１を使用しているスレッドの合計数に対するＣＰＵ使用率が１〜５％であるスレッドの数の割合を入力のデータセットとして使用する。

図１１は、異常検出モデルで用いるデータセットを説明する図である。ＣＰＵ使用率の測定中に、ＣＰＵ１０１を使用していたスレッドの合計数に対するＣＰＵ使用率１〜５％のスレッド数の割合をＴｈｒｅＣＵ０１０５Ｒとすると、
ＴｈｒｅＣＵ０１０５Ｒ
＝ＴｈｒｅＣＵ０１０５×１００／（ＮｕｍＯｆＴｈｒｅａｄ−ＴｈｒｅＣＵ００）
で表すことができる。
なお、前述したように、ＴｈｒｅＣＵ００は、ＣＰＵ使用率の測定中にＣＰＵ使用率が０％のスレッドの数である。ＴｈｒｅＣＵ０１０５は、ＣＰＵ使用率の測定中にＣＰＵ使用率が１〜５％のスレッドの数である。ＮｕｍＯｆＴｈｒｅａｄは、ＣＰＵ使用率の測定中に、実行されていたスレッドの合計数である。

学習装置３０は、上述したデータセットを用いて機械学習を行う異常検出モデルを生成する。例えば、学習装置３０は、機械学習のアルゴリズムとしてＯｎｅＣｌａｓｓＳＶＭを用いて、正常なときのデータセットを学習データとして機械学習させることで異常値との識別境界を決定し、当該識別境界を基準として異常の検出が可能な異常検出モデルを生成する。異常検出部１１２は、学習装置３０で機械学習された異常検出モデルを用いて、第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に対応する異常を検出する。このように、異常検出部１１２は、スレッドごとのＣＰＵ使用率を用いて機械学習された異常検出モデルを用いて異常を検出することで、高負荷の処理の時も低負荷の処理のときも精度よく異常を検出することができる。

また、前述したように、第１取得部１１１は、トリガイベントに応じて、システムの状態が予め設定された複数のそれぞれの状態となるタイミングで、システムの状態情報（例えば、スレッドごとのＣＰＵ使用率）を取得する。学習装置３０は、各システムの状態によってカテゴリ分けされたカテゴリごと（上記タイミングごと）に、システムの状態情報に基づくデータセットを用いて異常検出モデルを生成してもよい。異常検出部１１２は、上記システムの状態のカテゴリ（上記タイミング）のそれぞれで第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に対応する異常を、上記タイミングのそれぞれに対応する異常検出モデルを用いて検出する。

図１２は、システムの状態のカテゴリの例を示す図である。図示する例では、システムプロセスがＣＰＵを使用しているとき、システムがアイドル状態のとき、システムがレジューム後の３０秒以内、ＣＰＵ使用率が低い状態、ＣＰＵ使用率が高い状態、ＣＰＵ使用率が０％の状態の６つのカテゴリに分けて、各カテゴリが示すシステムの状態のときに取得されたシステムの状態情報（例えば、スレッドごとのＣＰＵ使用率）に基づいて異常検出モデルが生成されてもよい。なお、図示するシステム状態のカテゴリは一例であって、他のシステム状態としてもよい。

以上説明したように、本実施形態に係る電子機器１０は、プログラムに基づいて処理を実行するＣＰＵ１０１（プロセッサの一例）と、第１取得部１１１（取得部の一例）と、異常検出部１１２とを備えている。第１取得部１１１は、ＣＰＵ１０１が実行する処理におけるスレッドごとのＣＰＵ使用率を示す情報を取得する。異常検出部１１２は、第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に基づいて異常を検出する。これにより、電子機器１０は、単にＣＰＵ使用率によるのではなく、スレッドごとのＣＰＵ使用率に基づいて異常を検出することで、異常を精度よく検出することができる。

異常検出部１１２は、スレッドごとのＣＰＵ使用率と異常の有無に関する情報とに基づいて機械学習された異常検出モデル（学習済みモデルの一例）を用いて、第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に対応する異常を検出する。これにより、電子機器１０は、ＡＩを用いて異常を精度よく検出することができる。

具体的には、異常検出部１１２は、ＣＰＵ１０１を使用しているスレッドの合計数に対する特定のＣＰＵ使用率（例えば、ＣＰＵ使用率１〜５％）であるスレッドの数の割合に基づいて機械学習された異常検出モデルを用いて、第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に対応する異常を検出する。これにより、電子機器１０は、ＡＩを用いて異常を精度よく検出することができる。

第１取得部１１１は、ＣＰＵ１０１を含むシステムの状態が予め設定された複数のそれぞれの状態となるタイミングで、スレッドごとのＣＰＵ使用率を取得する。
異常検出部１１２は、上記タイミングのそれぞれで第１取得部１１１が取得したスレッドごとのＣＰＵ使用率に対応する異常を、上記タイミングのそれぞれに対応する異常検出モデルを用いて検出する。これにより、電子機器１０は、システムの状態ごとの異常検出モデルを用いて、システムの状態ごとに取得されたスレッドごとのＣＰＵ使用率から異常を検出することにより、異常を精度よく検出することができる。

プログラムに基づいて処理を実行するＣＰＵ１０１を備えた電子機器１０の異常を検出するための異常検出モデルは、処理におけるスレッドごとのＣＰＵ使用率を示す情報と異常の有無に関する情報とに基づいて、異常を検出するようコンピュータを機能させるための学習済みモデルである。これにより、異常検出モデルは、スレッドごとのＣＰＵ使用率に基づいて、異常を精度よく検出することができる。

なお、本実施形態では、ＣＰＵ１０１を使用しているスレッドの合計数に対するＣＰＵ使用率１〜５％であるスレッドの数の割合をデータセットとして、異常検出モデルを生成する例を説明したが、ＣＰＵ使用率１〜５％に限定されるものではない。例えば、ＣＰＵ１０１を使用しているスレッドの合計数に対する任意の特定のＣＰＵ使用率であるスレッドの数の割合をデータセットとしてもよい。

以上、図面を参照してこの発明の第１及び第２の実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。例えば、第１及び第２の実施形態で説明した構成は、任意に組み合わせてもよい。

また、上記実施形態では、異常検出モデルの機械学習のアルゴリズムとしてＯｎｅＣｌａｓｓＳＶＭを用いる例を説明したが、これに限られるものではなく、他の機械学習のアルゴリズムが用いられてもよい。また、原因検出モデルの機械学習のアルゴリズムとしてクラスタリングを用いる例を説明したが、これに限られるものではなく、他の機械学習のアルゴリズムが用いられてもよい。

また、上記実施形態では、システムの状態情報と学習済みモデルとを用いて異常の検出を行なう例を説明したが、これに限られるものではない。例えば、学習済みモデルを使用せずに、システムの状態情報の一部または全部と異常の有無（正常ｏｒ異常）とが関連付けられたデータテーブルを用いて異常の検出を行なうように構成されてもよい。また、学習済みモデルを使用せずに、システムの状態情報に基づいて異常を検出するアルゴリズムを具現化したプログラムを用いて異常の検出を行なうように構成されてもよい。また、同様に異常の原因の検出についても、学習済みモデルを使用せずに、異常情報の一部または全部と原因の一部または全部とが関連付けられたデータテーブル、または異常情報と分類情報とに基づいて異常の原因を検出するアルゴリズムを具現化したプログラムを用いて異常の検出を行なうように構成されてもよい。

また、上記実施形態では、システム処理部１００と独立に動作するＥＣ１８は、センサハブ、チップセット、などのいずれの処理部であってもよく、ＥＣ１８以外の処理部がＥＣ１８に代えて上述の処理を実行してもよい。また、システム処理部１００とＥＣ１８とは、一体化された集積回路で構成されてもよい。

なお、上述した電子機器１０は、内部にコンピュータシステムを有している。そして、上述した電子機器１０が備える各構成の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより上述した電子機器１０が備える各構成における処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。

また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部又は外部に設けられた記録媒体も含まれる。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に電子機器１０が備える各構成で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

また、上述した実施形態における電子機器１０が備える各機能の一部、または全部を、ＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。各機能は個別にプロセッサ化してもよいし、一部、又は全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

また、上記実施形態の電子機器１０は、パーソナルコンピュータに限られるものではなく、スマートフォンなどの携帯型の端末装置であってもよいし、ゲーム装置、家庭用電気製品、業務用電気製品など各種の電子機器に適用できる。

１自己診断システム、１０電子機器、１１通信部、１２表示部、１３スピーカ、１４入力部、１５電源部、１６ファン、１７温度センサ、１８ＥＣ、１９記憶部、２０データベース、３０学習装置、１００システム処理部、１０１ＣＰＵ、１０２ＧＰＵ、１０３メモリコントローラ、１０４Ｉ／Ｏコントローラ、１０５システムメモリ、１１０制御部、１１１第１取得部、１１２異常検出部、１１３第２取得部、１１４原因検出部、１１５データ提供部、１１６検出結果出力部、１９１第１情報記憶部、１９２第２情報記憶部、１９３第３情報記憶部、１９４異常検出モデル記憶部、１９５原因検出モデル記憶部、１９６検出結果記憶部

Claims

プログラムに基づいて処理を実行するプロセッサと、
前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得部と、
前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出部と、
を備える電子機器。
前記異常検出部は、
前記スレッドごとの前記プロセッサの使用率と異常の有無に関する情報とに基づいて機械学習された学習済みモデルを用いて、前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を検出する、
請求項１に記載の電子機器。
前記異常検出部は、
前記プロセッサを使用しているスレッドの合計数に対する特定の前記プロセッサの使用率であるスレッドの数の割合に基づいて機械学習された学習済みモデルを用いて、前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を検出する、
請求項２に記載の電子機器。
前記取得部は、
前記プロセッサを含むシステムの状態が予め設定された複数のそれぞれの状態となるタイミングで、前記スレッドごとの前記プロセッサの使用率を取得し、
前記異常検出部は、
前記タイミングのそれぞれで前記取得部が取得した前記スレッドごとの前記プロセッサの使用率に対応する異常を、前記タイミングのそれぞれに対応する学習済みモデルを用いて検出する、
請求項１から請求項３のいずれか一項に記載の電子機器。
プログラムに基づいて処理を実行するプロセッサを備える電子機器における制御方法であって、
取得部が、前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得ステップと、
異常検出部が、前記取得ステップより取得された前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出ステップと、
を有する制御方法。
プログラムに基づいて処理を実行するプロセッサを備える電子機器としてのコンピュータに、
前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報を取得する取得ステップと、
取得された前記スレッドごとの前記プロセッサの使用率に基づいて異常を検出する異常検出ステップと、
を実行させるためのプログラム。
プログラムに基づいて処理を実行するプロセッサを備えた電子機器の異常を検出するための学習済みモデルであって、
前記処理におけるスレッドごとの前記プロセッサの使用率を示す情報と異常の有無に関する情報とに基づいて、前記異常を検出するよう、
コンピュータを機能させるための学習済みモデル。