(57)【要約】【課題】サービスマンの再出動に伴うサービスコストの増加を抑制するシステムを提供する。【解決手段】エラー発生時に故障パーツとその対処とを含む診断情報を求める診断機能を備える電子機器を管理するシステムは、電子機器からエラー情報と診断情報とを受信する第１の受信手段と、電子機器から交換したパーツの情報を受信する第２の受信手段と、交換したパーツが前記第１の受信手段が受信した前記診断情報に示されるパーツと異なり、かつ、交換したパーツが寿命切れでない場合に、エラー情報で示すエラーに対応する診断情報に係るモデルをエラーが発生した電子機器の稼働情報を用いて構築または更新する処理手段と、前記モデルを前記診断情報に紐付けて管理する管理手段と、電子機器から新たに受信した診断情報の少なくとも一部が一致する診断情報に紐付けて管理されたモデルを利用して対処が必要なパーツを特定する分析手段とを有する。【選択図】図５
2020177276.tif 000002
【特許請求の範囲】
【請求項１】
エラー発生時にエラーに対応する故障パーツと該故障パーツに対する対処とを含む診断情報を求めるための診断機能を備える電子機器を管理するシステムであって、
電子機器から、エラーを示すエラー情報と、該エラーに対応する診断情報とを受信する第１の受信手段と、
電子機器から、前記エラー情報で示すエラーの解消のための対処の対象となった１以上のパーツの情報を受信する第２の受信手段と、
前記第２の受信手段が受信したパーツの情報に示されるパーツが前記第１の受信手段が受信した前記診断情報に示されるパーツと異なり、かつ、前記第２の受信手段が受信したパーツの情報に示されるパーツが寿命切れでない場合に、前記エラー情報で示すエラーに対応する診断情報に係るモデルを、エラーが発生した電子機器の稼働情報を用いて構築または更新する処理手段と、
構築または更新された前記モデルを、前記診断情報に紐付けて管理する管理手段と、
電子機器から新たに診断情報を受信した場合に、当該診断情報の少なくとも一部が一致する診断情報に紐付けて管理されたモデルを利用して、対処が必要なパーツを特定する分析手段と、を有することを特徴とするシステム。
【請求項２】
前記電子機器から受信した診断情報と、前記分析手段により特定されたパーツに係る診断情報とを、共に通知する通知手段を更に有することを特徴とする請求項１に記載のシステム。
【請求項３】
前記分析手段が特定した対処が必要なパーツの寿命の残りを算出する算出手段を更に有し、
前記通知手段は、診断情報に加え、前記算出手段が算出した前記寿命の残りを通知することを特徴とする請求項２に記載のシステム。
【請求項４】
前記処理手段は、前記エラー情報で示すエラーに対応する診断情報に係るモデルとして、パーツの異常度を計算するモデルを構築または更新し、
前記分析手段は、前記電子機器から受信した診断情報が示すパーツの異常度を計算し、該異常度が閾値以上であるパーツを、対処が必要なパーツとして特定することを特徴とする請求項１または２に記載のシステム。
【請求項５】
エラー発生時にエラーに対応する故障パーツと該故障パーツに対する対処とを含む診断情報を求めるための診断機能を備える電子機器を管理する故障診断方法であって、
電子機器から、エラーを示すエラー情報と、該エラーに対応する診断情報とを受信する第１の受信工程と、
電子機器から、前記エラー情報で示すエラーの解消のための対処の対象となった１以上のパーツの情報を受信する第２の受信工程と、
前記第２の受信工程において受信したパーツの情報に示されるパーツが前記第１の受信工程において受信した前記診断情報に示されるパーツと異なり、かつ、前記第２の受信工程において受信したパーツの情報に示されるパーツが寿命切れでない場合に、前記エラー情報で示すエラーに対応する診断情報に係るモデルを、エラーが発生した電子機器の稼働情報を用いて構築または更新する処理工程と、
構築または更新された前記モデルを、前記診断情報に紐付けて管理する管理工程と、
電子機器から新たに診断情報を受信した場合に、当該診断情報の少なくとも一部が一致する診断情報に紐付けて管理されたモデルを利用して、対処が必要なパーツを特定する分析工程と、を有することを特徴とする故障診断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、故障診断のシステムおよび故障診断方法に関する。
【背景技術】
【０００２】
ハードウェアの故障時に、故障パーツの特定や故障回復のための最適な処置（例えば、交換や清掃など）の提示（総称して故障診断という）を実現するためのシステムがある。特に、近年では、機械学習などのアルゴリズムの精度向上やクラウドなどの計算環境の普及に伴って、複数のデバイスから集めたデータを学習することで得られたモデルを用いて、故障診断をサーバ上で行うための仕組みも提案されている。故障した装置のメンテナンスを行うサービスマンは、故障診断の結果に応じて故障回復に必要な治具などを事前に準備して、修理に出動することができる。特許文献１は、情報処理装置が、ネットワークを介して接続されている複合機からの故障通知に応じて、該複合機の状態情報に基づいて複合機に発生した故障の原因及び複合機に発生した故障の原因に応じた処置を特定する技術を開示している。具体的には、情報処理装置は、複合機の状態情報に含まれるセンサーＸ〜Ｚのデータパターンと、故障原因診断モデルに含まれる通知された故障の原因特定に利用するデータパターンとを利用して、当該故障が発生した原因を特定している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１７−１７６１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、一般的な装置において、実際に壊れていてる故障箇所と、故障させた原因が異なることはよくあることである。例えば、ヒューズなどが切れてしまった場合、壊れている箇所自体はヒューズになる。しかしながら、ヒューズが切れる原因としては過電流などが考えられる。そのような場合、故障している部品（ヒューズ）を特定しそれを交換したとしても、過電流を引き起こす原因となる基板への対処をしなければ再度故障が発生し、サービスマンが再び修理に出動することになる。したがって、特許文献１の故障通知に対応する故障部位＋処置（ユニットコード）の特定だけでは、サービスマンの再出動が発生し、サービスコストが増加してしまう恐れがある。
【０００５】
本発明は、サービスマンの再出動に伴うサービスコストの増加を抑制するシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のシステムは、エラー発生時にエラーに対応する故障パーツと該故障パーツに対する対処とを含む診断情報を求めるための診断機能を備える電子機器を管理するシステムであって、電子機器から、エラーを示すエラー情報と、該エラーに対応する診断情報とを受信する第１の受信手段と、電子機器から、前記エラー情報で示すエラーの解消のための対処の対象となった１以上のパーツの情報を受信する第２の受信手段と、前記第２の受信手段が受信したパーツの情報に示されるパーツが前記第１の受信手段が受信した前記診断情報に示されるパーツと異なり、かつ、前記第２の受信手段が受信したパーツの情報に示されるパーツが寿命切れでない場合に、前記エラー情報で示すエラーに対応する診断情報に係るモデルを、エラーが発生した電子機器の稼働情報を用いて構築または更新する処理手段と、構築または更新された前記モデルを、前記診断情報に紐付けて管理する管理手段と、電子機器から新たに診断情報を受信した場合に、当該診断情報の少なくとも一部が一致する診断情報に紐付けて管理されたモデルを利用して、対処が必要なパーツを特定する分析手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、故障の原因となるパーツを特定することでサービスマンの再出動に伴うサービスコストの増加を抑制するシステムを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】システムの構成例を示す図である。
【図２】サーバおよび画像形成装置のハードウェアの構成を示す図である。
【図３】サーバおよび画像形成装置のソフトウェアの構成を示す図である。
【図４】デバイスデータの蓄積処理を示すフローチャートである。
【図５】異常度算出モデルの構築処理を示すフローチャートである。
【図６】実施例１における異常パーツの推定処理を示すフローチャートである。
【図７】実施例２における異常パーツの推定処理を示すフローチャートである。
【発明を実施するための形態】
【０００９】
（実施例１）
図１は、電子機器の故障診断を行うシステムの構成例を示す図である。なお、本実施例では電子機器の一例として画像形成装置１０１について説明を行うが、これに限られるものではない。電子機器は、エラー発生時にエラーに対応する故障パーツと該故障パーツに対する対処とを含む診断情報を求めるための診断機能を備える装置であればよい。画像形成装置１０１は、例えば、デジタル複合機、ファクシミリ装置、レーザービームプリンタ、インクジェットプリンタ、スキャナー装置等である。
【００１０】
電子機器の故障診断を行うシステムは、故障診断サービスサーバ（以下、診断サーバという）１０２を備え、ネットワーク１０３を介して診断サーバ１０２に接続されている電子機器（本実施例では、複数の画像形成装置１０１）の故障診断を行う。ネットワーク１０３は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現される、いわゆる通信ネットワークである。なお、診断サーバ１０２は、サーバ装置の他、サーバ装置を含むデータセンターにより提供されたリソースを利用した仮想マシンにより実現されてもよいし、アプリケーションにより実現されてもよい。
【００１１】
図２（Ａ）は、診断サーバ１０２のハードウェアの構成の一例を示す図である。診断サーバ１０２のハードウェアは、例えば、一般的な情報処理装置のハードウェアで構成することができる。診断サーバ１０２は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、キーボードコントローラ２０４、ディスプレイコントローラ２０５、ディスクコントローラ、ネットワークＩ／Ｆ２０７を備える。さらに、診断サーバ１０２は、キーボード２０８、ディスプレイ２０９、メモリ２１０を備える。
【００１２】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１は、読み取り可能な記憶媒体に格納されたプログラムを実行することにより、後述する各フローチャートの処理を実行する処理部として機能し、故障診断のシステム全体を統括制御する。ＣＰＵ２０１は、ＲＯＭ２０３内に記憶されたプログラムや、メモリ２１０からＲＡＭ２０２にロードされたＯＳ（オペレーションシステム）やアプリケーション等のプログラムを実行する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリア等として機能する。ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０３は、各種プログラムを記憶している。
【００１３】
キーボードコントローラ２０４は、キーボード２０８や図示しないポインティングデバイス（例えば、マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。ディスプレイコントローラ２０５は、ディスプレイ２０９の表示を制御する。ディスクコントローラ２０６は、各種データを記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）等のメモリ２１０へのデータアクセスを制御する。ネットワークＩ／Ｆ２０７は、ネットワーク１０３に接続されており、ネットワーク１０３に接続された画像形成装置１０１等の他の機器との通信を制御する。
【００１４】
図２（Ｂ）は、画像形成装置１０１のハードウェアの構成の一例を示す図である。画像形成装置１０１は、ＣＰＵ２２１、ＲＡＭ２２２、ＲＯＭ２２３、記憶装置２２４、ネットワークＩ／Ｆ２２５、デバイス制御部２２７、診断部２２９、入出力Ｉ／Ｆ２３０を備え、これらは内部バス２３１を介して互いに接続されている。さらに、画像形成装置１０１は、制御パーツ２２８および入出力装置２３１を備える。
【００１５】
ＣＰＵ２２１は、ＲＯＭ２２３等の読み取り可能な記憶媒体に格納されたプログラムを実行することにより、画像形成装置１０１全体を制御する。ＲＡＭ２２２は、ＣＰＵ２２１のメモリやワークエリアとして機能する。ＲＯＭ２２３は、各種プログラムを記憶している。記憶装置２２４は、外部記憶装置として機能する。ＣＰＵ２２１は、記憶装置２２４等の記録媒体に画像データを記録する。
【００１６】
ネットワークＩ／Ｆ２２５は、ネットワーク１０３に接続されており、ネットワーク１０３に接続された診断サーバ１０２等の他の機器との通信を制御する。デバイス制御部２２７は、各種制御パーツ２２８を制御する。各種制御パーツ２２８は、例えば印刷部やスキャナー等の画像形成装置の各種機能を実現するためのユニットである。診断部２２９は、画像形成装置１０１の故障箇所を特定する。診断部２２９は、デバイス制御２２７部を介して、各種制御パーツ２２８に電流を流したり実際に動作させたりすることによって各種制御パーツ２２８の動作状況を判断し、故障の有無を特定する。
【００１７】
入出力Ｉ／Ｆ２３０は、入出力装置２３１からの操作入力や入出力装置２３１への出力を制御する。入出力装置２３１は、例えば、ユーザに対して必要な情報を提供しユーザからの操作を受付け可能な表示装置（タッチパネルなど）や、ユーザが操作する各種ボタン等である。また、原稿を読み取り、入力として電子データを受付けるためのスキャン装置も入出力装置２３１に含まれてよい。
【００１８】
故障診断のシステムの機能は、大きく分けて「デバイスデータの蓄積」、「異常度算出モデルの作成」、「エラー発生時の異常パーツ推定」の３つに分けられる。各機能について、図３〜図６を用いて説明する。なお、下記で記載される表のスキーマやデータはあくまで一例であり、表のスキーマや各種データのフォーマットなどはこれに限られるものではない。
【００１９】
図３は、故障診断のシステムに係る診断サーバ１０２および画像形成装置１０１のソフトウェア構成の一例を示す図である。診断サーバ１０２の各部はＲＯＭ２０３にプログラムとして格納され、ＲＡＭ２０２上でＣＰＵ２０１によって実行される。また、画像形成装置１０１の各部は、ＲＯＭ２２３にプログラムとして格納され、ＲＡＭ２２３上でＣＰＵ２２１によって実行される。
【００２０】
画像形成装置１０１は、ジョブ実行部３１０、稼働情報取得部３０２、稼働情報送信部３０３、エラー検知部３０４、診断部３０５、診断結果送信部３０６、交換パーツ検知部３０７、交換パーツ送信部３０８を備える。ジョブ実行部３０１は、画像形成装置１０１に投入されたジョブを実行する。例えば、印刷ジョブが投入された場合は、ジョブ実行部３０１は印刷ジョブに基づいて印刷処理を実行する。稼働情報取得部３０２は、画像形成装置１０１の稼働情報を収集する。稼働情報送信部３０３は、稼働情報取得部３０２が取得した稼働情報を診断サーバ１０２に送信する。
【００２１】
エラー検知部３０４は、画像形成装置１０１でのエラーの発生を検知する。診断部３０５は、エラー検知部３０４でエラーが検知された場合に故障診断を行う。故障診断で診断部３０５は、エラーに対応する故障パーツの特定と、故障パーツに対する対処とを含む診断情報を求める。診断結果送信部３０６は、診断部３０５による故障診断の結果である診断情報を診断サーバ１０２に送信する。交換パーツ検知部３０７は、画像形成装置１０１においてパーツが交換されたことを検知する。交換パーツ送信部３０８は、交換パーツ検知部３０７が検知したパーツの交換を示すパーツの情報を診断サーバ１０２に送信する。
【００２２】
診断サーバ１０２は、デバイスデータ受信部３２１、デバイスデータ保存部３２２、非故障パーツ判断部３２３、非寿命切れパーツ判断部３２４、異常度算出モデル作成部３２５、モデル保存部３２６、異常度算出部３２７、診断結果通知部２３８を備える。また、診断サーバ１０２は、残寿命算出部３２９を備えていてもよい。
【００２３】
デバイスデータ受信部３２１は、画像形成装置１０１から様々な情報を受信する。デバイスデータ受信部３２１が受信する情報には、エラーを示すエラー情報と、該エラーに対応する診断情報、画像形成装置１０１の稼働情報、パーツの交換情報等が含まれる。デバイスデータ保存部３２２は、デバイスデータ受信部３２１が受信した画像形成装置１０１の情報を保存する。
【００２４】
非故障パーツ判断部３２３は、画像形成装置１０１で交換されたパーツが、エラーに対応する診断情報で示される故障パーツと同じか否かを判断する。非寿命切れパーツ判断部３２４は、画像形成装置１０１で交換されたパーツが寿命切れであったか否かを判断する。異常度算出モデル作成部３２５は、デバイスデータ保存部３２２に保存された画像形成装置１０１の稼働状況のデータに基づいて、パーツの異常度を算出するための異常度算出モデルを構築および更新する処理を行う。モデル保存部３２６は、異常度算出モデル作成部３２５が生成した異常度算出モデルを保存する。異常度算出モデルは、故障コードで示すパーツ以外のパーツに対する対処（交換、清掃、調整など）が行われた場合に、該パーツが、他のパーツの故障の再発原因になり得るパーツであったかどうかを特定するためのモデルである。
【００２５】
異常度算出部３２７は、新たに画像形成装置１０１から受信した診断情報の少なくとも一部が一致する過去の診断情報に紐付けて管理された異常度算出モデルを利用して、エラーを解消するために対処が必要なパーツを特定する。診断結果通知部２３８は、画像形成装置１０１から受信した診断情報に加え、異常度算出部３２７が特定した対処が必要なパーツの情報をサービスマン等に通知する。残寿命算出部３２９は、異常度算出部３２７が特定した対処が必要なパーツの寿命の残りを算出する。
【００２６】
まず、デバイスデータの蓄積について、図４を用いて説明する。診断サーバ１０２は、管理対象すなわち故障診断の対象となる画像形成装置１０１の稼働状況および故障のデータをデバイスデータとして蓄積する。ステップＳ４０１で、画像形成装置１０１のジョブ実行部３０１は、印刷やスキャンなどのジョブを実行する。ステップＳ４０２で、画像形成装置１０１のエラー検知部３０４は、ステップＳ４０１のジョブ実行中にエラーが発生したか否かを判断する。エラーが発生したと判断した場合はステップＳ４０３に遷移し、エラーが発生したと判断しなかった場合はステップＳ４０６に遷移する。
【００２７】
ステップＳ４０３で、画像形成装置１０１の診断部３０５は、故障診断を行い、ステップＳ４０２で検知したエラーを引き起こした故障パーツの特定を行う。故障パーツの特定方法は特に限定されない。例えば、あるモーターの故障を判断する場合には、モーターに電流を流し、モーターの回転可否によって故障有無を特定する。本実施例では、故障パーツの特定の結果として下記の表１に示す３パターンを想定する。
【表１】
2020177276.tif 000003
【００２８】
パターンＡは、診断部３０５によって、故障しているパーツ（部品）が特定できた場合である。故障しているパーツが複数ある場合には、全てのパーツが特定できているものとする。パターンＢは、診断部３０５によって、１つ以上の故障可能性のあるパーツが特定された場合である。すなわち、パターンＢは、故障可能性のあるパーツを複数特定することはできたが、故障可能性のある複数のパーツの内いずれかの部品が故障しているかを特定できなかった場合である。例えば、モーターとケーブルの２つのうち、いずれか一方が壊れていることまで特定できた場合などが、パターンＢに該当する。パターンＣは、診断部３０５が、故障しているパーツおよび故障可能性のあるパーツを１つも特定できなかった場合である。また、故障診断の処理ができなかった場合もパターンＣに該当する。
【００２９】
診断部３０５は、診断結果に応じて表１に示す故障コードを出力する。故障コードは、前３桁の数字で各パターンを示し、後ろ４桁で故障部品を示している。具体的には、前３桁は、００１がパターンＡ、００２がパターンＢ、９９９がパターンＣであることを示す。後ろ４桁は、例えば、００００が基板、０００１がモーター、０００２がケーブルであることを示す。パターンＡの行に記載されている故障コード（００１−０００）は、基板が壊れていることが確定した事を示す。また、パターンＢの行に記載されている故障コード（００２−００００，００２−０００１）は、基板またはケーブルが故障していることまで特定できたことを示す。なお、パターンＣの行に記載されている前３桁が９９９の故障コードの場合は、後ろ４桁の数字に意味はない。
【００３０】
ステップＳ４０４で、画像形成装置１０１の診断結果送信部３０６は、エラーの発生を示すエラー情報と、故障データを診断サーバ１０２に送信する。故障データは、該エラーに対応するの診断情報であり、診断部３０５がステップＳ４０３で出力した故障コード、エラーの内容を示すエラーＩＤ、エラーの発生日時、ステップＳ４０１で実行したジョブを一意に識別するジョブＩＤを含む。ステップＳ４０５で、診断サーバ１０２のデバイスデータ受信部３２１は、ステップＳ４０４で画像形成装置１０１から送信された故障データを受信し、デバイスデータ保存部３２２に保存する。デバイスデータ受信部３２１は、例えば、下記の表２の故障データテーブルに受診した故障データを保存する。
【表２】
2020177276.tif 000004
【００３１】
ステップＳ４０６で、画像形成装置１０１の稼働情報取得部３０２は、稼働データを診断サーバ１０２に送信する。稼働データは、ステップＳ４０１で実行したジョブを一意に識別するジョブＩＤ、ジョブの実行によって変化した情報を含む。ジョブの実行によって変化した情報は、例えば、総プリント枚数や、デバイス内の温度や湿度、各種パーツの摩耗度等である。なお、本実施例ではジョブの実行（ステップＳ４０１）によりエラーが発生した場合（ステップＳ４０２がＹｅｓ）を前提にしているため、ジョブの実行によって変化した情報を稼働データとしたが、これに限られるものではない。診断部３０５による故障診断で、エラーの解消のための対処の対象となったパーツの状態を稼働情報としてもよいし、画像形成装置１０１の各部の状態を稼働情報としてもよい。
【００３２】
ステップＳ４０７で、診断サーバ１０２のデバイスデータ受信部３２１は、ステップＳ４０６で画像形成装置１０１から送信された稼働データを受信し、デバイスデータ保存部３２２に保存する。デバイスデータ受信部３２１は、例えば、下記の表３の稼働データテーブルに受診した稼働データを保存する。
【表３】
2020177276.tif 000005
【００３３】
このように、図４のフローチャートに従って処理をすることで、デバイスの稼働データおよび故障診断の結果である故障データを診断サーバ１０２に保存することが可能となる。診断サーバ１０２のデバイスデータ保存部３２２に保存した画像形成装置１０１の稼働データおよび故障データは、後述する異常度算出モデルの学習に利用する。
【００３４】
次に、異常度算出モデルの作成について、図５を用いて説明する。図５は、異常度算出モデルの作成処理を示すフローチャートである。なお、図４を用いて説明したデバイスデータの蓄積によって、診断サーバ１０２上にはデバイスのデータ（稼働データおよび故障データ）がある程度保存されているものとする。また、図５は、エラーが起きた場合（ステップＳ４０２がＹｅｓの場合）のみを記載しているため、図４に示した故障データおよび稼働データの送信フローから一部簡略化して記載している。
【００３５】
ステップＳ５０１で、画像形成装置１０１の診断結果送信部３０６は、故障データを診断サーバ１０２に送信する。ステップＳ５０１は、図４のステップＳ４０４と同様である。ステップＳ５０２で、診断サーバ１０２のデバイスデータ受信部３２１は、画像形成装置１０１から故障データを受信し、デバイスデータ保存部３２２に保存する。ステップＳ５０２は、図４のステップＳ４０５と同様である。
【００３６】
画像形成装置１０１の修理を行う作業者（サービスマン）は、故障データに応じてエラーが発生したパーツの交換等の作業を行う。ステップＳ５０３で、画像形成装置１０１の交換パーツ検知部３０７は、画像形成装置１０１においてパーツが交換されたことを検知する。検知方法としては、例えば、パーツにシリアルナンバーつきのＩＣタグが埋め込まれており、シリアルナンバーが変更したことをもってパーツの交換を検知する方法がある。また、作業者がボタンなどを押下する等して画像形成装置１０１を操作して、パーツを交換したことを画像形成装置１０１に直接入力するようにしてもよい。なお、本実施例ではエラーへの対処としてパーツの交換を行った場合について説明するが、サービスマンによるエラーへの対処はこれに限られるものではない。そのため、交換パーツ検知部３０７は、交換されたパーツ以外にも、エラー情報で示すエラーの解消のための対処（例えば、清掃、調整など）の対象となった１以上のパーツの情報を検知するようにしてもよい。
【００３７】
ステップＳ５０４で、画像形成装置１０１の交換パーツ送信部３０８は、ステップＳ５０３で検知したパーツの交換情報を診断サーバ１０２へ送信する。パーツの交換情報には、交換されたパーツの種別を一意に識別するためのＩＤおよび交換日時が含まれる。ステップＳ５０５で、診断サーバ１０２のデバイスデータ受信部３２１は、画像形成装置１０１からパーツの交換情報を受信し、受信したパーツの交換情報を非故障パーツ判断部３２３に出力する。非故障パーツ判断部３２３は、受信したパーツの交換情報が示すパーツが、ステップＳ５０２で受信した故障コードが示すパーツと同じか否かを確認する。同じパーツであった場合には本処理を終了する。一方、異なるパーツであった場合には、ステップＳ５０６に遷移する。なお、ステップＳ５０３で説明したようにパーツの交換情報には、交換されたパーツの情報に限られず、エラー情報で示すエラーの解消のための対処の対象となったパーツの情報が含まれる。
【００３８】
ステップＳ５０６で、診断サーバ１０２の非故障パーツ判断部３２３は、パーツの交換タイミングが故障データを受信してから一定時間以内か否か判定する。本実施例では、パーツの交換タイミングが故障データを受信してから一定時間以内か否かは、ステップＳ５０５でパーツの交換情報を受信した時刻とステップＳ５０２で故障データを受信した時刻の差が閾値以内か否かにより判断する。なお、パーツの交換情報に含まれる交換日時とステップＳ５０２で故障データを受信した時刻の差を閾値と比較するようにしてもよい。本ステップでは、パーツの交換がエラー発生から一定の時間以内に行われたか否か判定することで、パーツの交換がエラーへの対応として行われたか否か判断している。非故障パーツ判断部３２３は、交換のタイミングが一定時間以内である場合は、パーツの交換はエラーへの対応の一貫として行われたと判断し、ステップＳ５０７に遷移する。一方、交換のタイミングが一定時間以上経過している場合には、エラーの原因として特定されたパーツ以外のパーツが交換されたと判断し、本処理を終了する。
【００３９】
ステップＳ５０７で、診断サーバ１０２の非寿命切れパーツ判断部３２４は、交換したパーツの交換理由が寿命切れか否かを判断する。ここで、寿命切れとは、例えばトナーなどの消耗品であれば、その消耗品がなくなることを意味する。また、ドラムなどのパーツの場合は、これ以上使うと画質などが劣化し、ユーザが求める画質での印刷ができなくなる状態になったことを意味する。寿命切れか否かを判断するための方法としては、単回帰や時系列分析などのアルゴリズムを用いて交渉寿命枚数に到達するタイミングを推定する手法などがある。本実施例においては、特にそれらの手法に限定はなく、いずれかの方法を用いて該パーツが寿命切れか否かを判断することとする。非寿命切れパーツ判断部３２４は、寿命切れであった場合には本処理を終了させ、寿命切れでなかった場合には、ステップＳ５０８に遷移する。
【００４０】
ステップＳ５０８で、診断サーバ１０２の異常度算出モデル作成部３２５は、後述するモデル保存部３２６に、ステップＳ５０２で保存した故障コードに紐付いた異常度算出モデルが構築されているか否かを確認する。異常度算出モデルが存在する場合には、モデルの情報を取得した後ステップＳ５０９に遷移する。一方、異常度算出モデルが存在しない場合には、ステップＳ５１０に遷移する。
【００４１】
ステップＳ５０９で、診断サーバ１０２の異常度算出部３２７は、取得した異常度算出モデルを用いて交換パーツの異常度を算出し、異常度が閾値以下か否かを判断する。交換パーツの異常度が閾値以下であった場合は、本処理を終了する。一方、交換パーツの異常度が閾値より高い場合には、ステップＳ５１０に遷移する。
【００４２】
ステップＳ５０５、ステップＳ５０７、ステップＳ５０９の３つの処理は、ステップＳ５０５で受信した交換パーツの交換理由を識別し、実際にパーツを故障させた原因のパーツ情報のみを取得するための処理である。具体的には、交換業務を行う作業者（サービスマン）がパーツを交換する理由としては、１：壊れたパーツである、２：寿命切れのパーツである、３：理由もなく交換した、４：壊れた原因となったパーツである、の４つに大別される。本処理では、４：壊れた原因となったパーツであるパターンのデータを収集して異常度を算出するためのモデルを構築するため、１乃至３のパターンを除外する必要がある。１のパターンをステップＳ５０５の処理で、２のパターンをステップＳ５０７の処理で、３のパターンをステップＳ５０９の処理で除外し、残ったデータ（４のパターン）を用いて、ステップＳ５１０の処理でモデル構築を行う。
【００４３】
ステップＳ５１０で、診断サーバ１０２の異常度算出モデル作成部３２５は、デバイスデータ保存部３２２に保存された稼働状況のデータに基づいて、該パーツの異常度を算出するためのモデルを機械学習などの技術を用いて構築または更新する。ここでいう異常度は、通常とは違う動きをしたときの、通常状態からの解離度を示すものであり、異常度が大きいほど異常、つまりパーツに不具合が発生している可能性があることを示す。本実施例においては、異常度が大きいパーツをステップＳ５０２で受信した故障データが示すパーツを壊したパーツとして扱う。異常度を算出するためのアルゴリズムはいくつもあるが、有名なアルゴリズムとしてはホテリング理論を用いたものがある。ホテリング理論は統計モデルに基づく異常検知技術であり、あるセンサー値の分布が正規分布に従う場合などに利用される技術である。ホテリングの理論においては、データの分布を正規分布として仮定しており、母平均μ、母標準偏差σを用いて、その異常度ａは、下記の式によって求めることができる。
【数１】
2020177276.tif 000006
例えば、電流の値を稼働状況のデータとして取得していた場合、その電流値が突発的に高い値もしくは低い値を示した場合に、異常度ａは高い値を示す。
【００４４】
ホテリング理論以外にも、異常検知のためのアルゴリズムは公知の技術として多く存在している。例えば、ニューラルネットワークを用いた異常検知の理論として自己連想ニューラルネットワークなどが存在する。自己連想ニューラルネットワークは、正常なデータを復元可能なネットワークを、自己符号化などのアルゴリズムを用いて構築し、そのネットワーク入力と出力を比較することで、異常度を算出するアルゴリズムである。本実施例においては何れのアルゴリズムを用いても構わない。
【００４５】
ステップＳ５１１で、診断サーバ１０２の異常度算出モデル作成部３２５は、ステップＳ５１０にて構築した異常度算出モデル、ステップＳ５０２で受信した故障コード、ステップＳ５０５で受信したパーツ情報を紐付けて保存する。異常度算出モデルとしては、ステップＳ５１０にてアルゴリズムを適用して得られたパラメータを保存する。パラメータとは、例えば、ホテリング理論の場合は平均や分散、自己連想ニューラルネットワークの場合は、ノード数やノード間の重みや活性化関数の情報となる。
【００４６】
このように、図５のフローチャートに従って処理をすることで、デバイスの稼働データに基づいて、故障の原因となったパーツの異常度を求めるためのモデルの構築および更新が可能となる。
【００４７】
最後に、エラー発生時の異常パーツ推定について、図６を用いて説明する。図６は、実施例１におけるエラー発生時の異常パーツの推定処理を示すフローチャートである。なお、図６のフローチャートにおいても、図５の場合と同様に、エラーが起きた場合（ステップＳ４０２がＹｅｓの場合）のみを記載しているため、図４に示した故障データおよび稼働データの送信フローから一部簡略化して記載している。
【００４８】
ステップＳ６０１で、画像形成装置１０１のエラー検知部３０４は、エラーを検知する。ステップＳ６０２で、画像形成装置１０１の診断部３０５は、故障部品を特定し、故障コードを求める。ステップＳ６０３で、画像形成装置１０１の診断結果送信部３０６は、ステップＳ６０２で求めた故障コードを含む故障データを診断サーバ１０２に送信する。ステップＳ６０１、ステップＳ６０２、ステップＳ６０３はそれぞれ、図４のステップＳ４０２、ステップＳ４０３、ステップＳ４０４に対応している。
【００４９】
ステップＳ６０４で、診断サーバ１０２のデバイスデータ受信部３２１は、画像形成装置１０１から故障コードを受信する。ステップＳ６０５で、診断サーバ１０２の異常度算出部３２７は、受信した故障コードのパターンを確認し、故障箇所が特定できているか否か判定する。異常度算出部３２７は、受信した故障コードのパターンがパターンＡ（故障部品が特定）である場合は、故障箇所が特定できていると判定し、ステップＳ６０７に遷移する。一方、受信した故障コードのパターンがパターンＢ（故障可能性のある部品が複数存在）もしくはパターンＣ（診断出来なかった）である場合は、故障箇所が特定できていないと判定し、ステップＳ６０６に遷移する。
【００５０】
ステップＳ６０６で、診断サーバ１０２の異常度算出部３２７は、受信した故障コードのパターンを確認し、故障の可能性のある複数のパーツの候補が特定できているか否か判定する。異常度算出部３２７は、故障コードのパターンがパターンＢ（故障可能性のある部品が複数存在）である場合には、故障の可能性のある複数のパーツの候補が特定できていると判定し、ステップＳ６０８に遷移する。一方、異常度算出部３２７は、故障コードのパターンがパターンＣ（診断出来なかった）である場合には、故障の可能性のある複数のパーツの候補が特定できていないと判定し、ステップＳ６１２に遷移する。
【００５１】
ステップＳ６０７で、診断サーバ１０２の異常度算出部３２７は、受信した故障コードに紐付いた異常度算出モデルがモデル保存部３２６に保存されているか否かを確認する。受信した故障コードに紐付いた異常度算出モデルが保存されていない場合には、ステップＳ６１３に遷移する。一方、受信した故障コードに紐付いた異常度算出モデルが保存されている場合には、ステップＳ６０９に遷移する。
【００５２】
ステップＳ６０８で、診断サーバ１０２の異常度算出部３２７は、受信した複数の故障可能性のある故障コードのそれぞれに紐付いた異常度算出モデルがモデル保存部３２６に１つ以上保存されているか否かを確認する。すなわち、異常度算出部３２７は、受信した診断情報の少なくとも一部が一致する診断情報に紐付けて管理された異常度算出モデルがあるか否か判定する。受信した故障コードに紐付いた異常度算出モデルが保存されていない場合には、ステップＳ６１３に遷移する。一方、受信した故障コードに紐付いた異常度算出モデルが保存されている場合にはステップＳ６０９に遷移する。
【００５３】
ステップＳ６０９で、診断サーバ１０２の異常度算出部３２７は、受信した１つ以上の故障コードに紐付いた異常度算出モデルをモデル保存部３２６より取得する。以下の処理においては、故障コードに応じた異常度算出モデルを用いて処理を行う。ステップＳ６１０で、診断サーバ１０２の異常度算出部３２７は、ステップＳ６０９で取得した異常度算出モデルを、デバイスの稼働状況データに対して適用し、デバイスの各パーツの異常度を算出する。
【００５４】
ステップＳ６１１で、診断サーバ１０２の異常度算出部３２７は、ステップＳ６０９で算出した異常度が閾値以上となるパーツ、すなわち対処が必要なパーツが存在するか否かを判断する。異常度が閾値以上となる対処が必要なパーツが存在する場合には、ステップＳ６１２に遷移する。一方、異常度が閾値以上となるパーツが存在しない場合には、ステップＳ６１３に遷移する。
【００５５】
ステップＳ６１２で、診断サーバ１０２の診断結果通知部３２８は、ステップＳ６１１で求めたパーツの情報を、ステップＳ６０４で受信した故障コードに付与する。例えば、表１に示すパターンＡの故障コードが送信されてきた時には、新たな故障コードが追加された情報（例えば｛“００１−００００”：“００５−０００３”｝）を発行する。ここで、００５−０００３は、異常度が高いと算出されたパーツを示す故障コードである。００５は、異常度算出の結果、発行されたパターンであることを示し、０００３は異常度が高い部品を示すものとする。また、パターンＢに示す故障コードが発行されてきた場合には、｛“００２−００００”：“００５−００１０”，“００２−０００１”：“００５−００１１”｝、のようにそれぞれの故障コードに特定したパーツの情報を紐付けて故障コードを発行する。
【００５６】
ステップＳ６１３で、診断サーバ１０２の診断結果通知部３２８は、ステップＳ６１２で生成した故障コードを、予め登録してあるシステムや交換業務を行うサービスマンに通知する。通知を受けたシステムやサービスマンは、異常度が高いと診断されたパーツも含めて準備し故障の修理に出動する。
【００５７】
以上、本実施例によると、故障が確定したパーツの情報に加え、故障の原因となった可能性がある異常なパーツの通知も可能になる。サービスマンは故障したパーツに加え、故障の原因となった可能性のあるパーツも含めて準備をして修理に向かうことができるため、サービスマンの再出動を抑制することが可能となる。
【００５８】
（実施例２）
実施例１においては、異常度算出モデルを用いて、異常度の高いパーツの情報をデバイス（画像形成装置１０１）から送信された故障コードに紐付けて通知するための仕組みを説明した。一般的に、デバイスのパーツは経年劣化するため、寿命切れに近い状態になったパーツは通常とは異なる動きをして、結果として実施例１で述べた異常度算出モデルが算出する値も高い傾向になることがある。ドラムや定着器などのパーツコストが高いパーツに関しては、極力長く利用し続けてもらうことがサービスコスト低減につながる。そこで、異常度が高い理由が寿命切れに近い状態であるためということが予め分かれば、当該パーツをあえて交換しないと判断することができ、パーツコストが高いパーツを寿命が完全に切れるまで使い続けることができる。実施例１では異常度が高い理由の考慮していなかったが、実施例２においては異常度が高いと判断されたパーツに対して寿命の計算も行い、寿命切れが近いと言うことが推定されれば、その寿命に関する情報も通知するようにするようにする。
【００５９】
実施例２の故障診断のシステムの構成、デバイスデータの蓄積処理、異常度算出モデルの作成処理は実施例１と同様である。以下では図７を用いて、エラー発生時の異常パーツの推定処理について実施例１と異なる点についてのみ説明する。図７は、実施例２におけるエラー発生時の異常パーツの推定処理を示すフローチャートである。実施例２におけるエラー発生時の異常パーツの推定処理は、図６に示される実施例１のエラー発生時の異常パーツの推定処理にステップＳ７０１乃至ステップＳ７０３の処理を追加することで実現されるため、追加した処理部分だけ説明する。
【００６０】
ステップＳ７０１で、診断サーバ１０２の残寿命算出部３２９は、ステップＳ６１１で異常度が閾値以上と判定されたパーツの寿命を計算する。寿命の計算においては、例えば、ステップＳ５０７で述べた寿命切れまでの期間を算出するためのアルゴリズムを用いる。ステップＳ７０２で、診断サーバ１０２の残寿命算出部３２９は、ステップＳ７０１で求めた異常度の高いパーツの寿命が閾値以下であるか否か判定する。異常度の高いパーツの寿命が閾値以下である場合にはステップＳ７０３に遷移する。一方、異常度の高いパーツの寿命が閾値より大きい場合は、ステップＳ６１２に遷移する。
【００６１】
ステップＳ７０３で、診断サーバ１０２の診断結果通知部３２８は、ステップＳ７０２で求めた残寿命に関する情報をサービスマン等に通知する情報に付加する。具体的には、実施例１における表１のパターンＢに対応する通知情報｛“００２−００００”：“００５−００１０”，“００２−０００１”：“００５−００１１”｝について、００１０が示すパーツの残寿命が閾値以下であった場合を例にあげる。この場合、｛“００２−００００”：｛“異常パーツ”：“００５−００１０”、“残寿命”：“１０日”｝，“００２−０００１”：｛“異常パーツ”：“００５−００１１”｝｝のように、残寿命に関する情報を通知情報に付与する。
【００６２】
以上、本実施例によると、異常度が高くなったパーツの寿命もサービスマンに通知することが可能となり、パーツの寿命に応じた交換作業が可能となる。なお、本実施例は、異常度が高くなったパーツの異常の原因もサービスマンに通知することで、原因に応じた交換作業を行うことを可能にするものであり、パーツの異常の原因として寿命を例に説明したがこれに限られるものではない。
【００６３】
（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６４】
以上、本発明の好ましい実施例について説明したが、本発明は、これらの実施例に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
2020177276.tif 000007
【図２】
2020177276.tif 000008
【図３】
2020177276.tif 000009
【図４】
2020177276.tif 000010
【図５】
2020177276.tif 000011
【図６】
2020177276.tif 000012
【図７】
2020177276.tif 000013