(57)【要約】      （修正有）【課題】ネットワークデバイス内での診断結果を反映した診断モデルの構築を可能とし、故障診断の精度を向上させることができるシステム、システムの制御方法及びプログラムを提供する。【解決手段】故障診断サービスサーバは、画像形成装置102で検出されたエラーイベントに対応して該画像形成装置102で診断された該エラーイベントに対して行われるべき対処の診断結果を取得しS604、診断結果がエラーイベントに対して行われるべき候補となる複数の対処を示す場合S605でNo、該候補となる複数の対処と、該エラーイベントに対して診断モデルを用いて予測された結果とを比較しS607、S608、候補となる複数の対処と予測の結果とが異なる場合S608でNo、履歴から一部の稼動情報を取得し、診断モデルに含まれるそれぞれ異なる予測を行う複数の階層の中の後段の階層に対して、該取得した一部の稼働情報に従う再学習を実行するS610。【選択図】図６
2020009156.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデバイスから収集された稼働情報、及び、ネットワークデバイスに対する対処の履歴に基づく、ネットワークデバイスで検出されたエラーイベントへの適切な対処を予測するモデルを保持する保持手段と、
前記ネットワークデバイスで検出されたエラーイベントに対応して該ネットワークデバイスで診断された該エラーイベントに対して行われるべき対処の診断結果を取得する取得手段と、
前記診断結果が前記エラーイベントに対して行われるべき候補となる複数の対処を示す場合、該候補となる複数の対処と、該エラーイベントに対して前記モデルを用いて予測された結果とを比較する比較手段と、
前記比較の結果、前記候補となる複数の対処と前記予測の結果とが異なる場合、前記履歴から一部の稼動情報を取得し、前記モデルに含まれるそれぞれ異なる予測を行う複数の階層の中の後段の階層に対して、該取得した一部の稼働情報に従う再学習を実行する実行手段と、
を有することを特徴とするシステム。
【請求項２】
前記履歴では、前記ネットワークデバイスに対する対処は、前記稼働情報と対応付けされており、
前記再学習に利用される前記一部の稼働情報は、前記履歴において、前記候補となる複数の対処のいずれかと同一の対処がネットワークデバイスに対する対処として対応付けされている稼動情報であることを特徴とする請求項１に記載のシステム。
【請求項３】
前記再学習は、前記複数の階層の中の最後段の階層に対して実行されることを特徴とする請求項１又は２に記載のシステム。
【請求項４】
前記再学習では、前記最後段の階層のノードを前記候補となる複数の対処に対応つけ、１つ前の階層のノードから前記最後段の階層のノードへの重みを調整することを特徴とする請求項３に記載のシステム。
【請求項５】
前記ネットワークデバイスで検出されたエラーイベントに対する対処として、前記モデルを用いて予測した結果を出力する出力手段を有し、
前記出力手段は、前記再学習が行われた場合には、該再学習により調整されたモデルを用いて予測した結果を出力することを特徴とする請求項１〜４のいずれか１項に記載のシステム。
【請求項６】
前記出力手段は、前記診断結果が、前記ネットワークデバイスで特定された前記エラーイベントに対して行われるべき対処を示す場合、該特定された対処を出力することを特徴とする請求項５に記載のシステム。
【請求項７】
前記出力手段は、前記診断結果が、前記ネットワークデバイスで特定された前記エラーイベントに対して行われるべき対処、及び、候補となる複数の対処のいずれも特定できなかったことを示す場合、前記モデルを用いて予測された結果を出力することを特徴とする請求項６に記載のシステム。
【請求項８】
前記対処とは、前記ネットワークデバイスの特定のパーツに対する特定の処置、又は、前記ネットワークデバイスに対する特定の操作を示すことを特徴とする請求項１に記載のシステム。
【請求項９】
前記モデルを用いた予測では、最も確率が高いものを予測の結果とする、又は、最も確率が高いものから所定のしきい値以内の確率をもつものを予測の結果とすることを特徴とする請求項１〜８のいずれか１項に記載のシステム。
【請求項１０】
ネットワークデバイスから収集された稼働情報、及び、ネットワークデバイスに対する対処の履歴に基づく、ネットワークデバイスで検出されたエラーイベントへの適切な対処を予測するモデルを保持する保持手段を有するシステムの制御方法であって、
前記ネットワークデバイスで検出されたエラーイベントに対応して該ネットワークデバイスで診断された該エラーイベントに対して行われるべき対処の診断結果を取得する取得ステップと、
前記診断結果が前記エラーイベントに対して行われるべき候補となる複数の対処を示す場合、該候補となる複数の対処と、該エラーイベントに対して前記モデルを用いて予測された結果とを比較する比較ステップと、
前記比較の結果、前記候補となる複数の対処と前記予測の結果とが異なる場合、前記履歴から一部の稼動情報を取得し、前記モデルに含まれるそれぞれ異なる予測を行う複数の階層の中の後段の階層に対して、該取得した一部の稼働情報に従う再学習を実行する実行ステップと、
を有することを特徴とするシステムの制御方法。
【請求項１１】
コンピュータに、請求項１０に記載の方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器の故障診断を行うシステム、システムの制御方法及びプログラムに関する。
【背景技術】
【０００２】
従来、ハードウェアの故障時に、故障パーツの特定や、故障回復のための最適な処置（交換や清掃など）の提示（総称して故障診断と呼称）を実現するためのシステムが構築されてきた。特に、近年では、機械学習などのアルゴリズムの精度向上や、クラウドなどの計算環境の普及に伴って、複数のデバイスから集めたデータを学習することで得られたモデルを用いて、故障診断をサーバ上で行うための仕組みも提案されてきている。
【０００３】
特許文献１は、サブシステムからの故障信号を受けとり故障診断を行うためのシステムであり、複数の故障診断結果を受け取った場合、過去の組み合わせ事例から確率の高い候補を選択して、それに応じた診断結果を出力する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６―２５２４２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に示される技術では、デバイスからの信号を基に過去の実績に照らし合わせ、確率が高くなる候補を自動的に選択する。
しかし、デバイスからの信号が非常に稀に発生するような組み合わせの場合など、過去の実績にそぐわない場合も考えられる。このような場合、単純に過去の組み合わせ事例を参照するだけでは、精度の高い診断を行うことは難しい。
【０００６】
本発明は、上記の課題を解決するためになされたものである。本発明の目的は、ネットワークデバイス内での診断結果を反映した診断モデルの構築が可能となり、故障診断の精度を向上させることを可能とする仕組みを提供するものである。
【課題を解決するための手段】
【０００７】
本発明は、ネットワークデバイスから収集された稼働情報、及び、ネットワークデバイスに対する対処の履歴に基づく、ネットワークデバイスで検出されたエラーイベントへの適切な対処を予測するモデルを保持する保持手段と、前記ネットワークデバイスで検出されたエラーイベントに対応して該ネットワークデバイスで診断された該エラーイベントに対して行われるべき対処の診断結果を取得する取得手段と、前記診断結果が前記エラーイベントに対して行われるべき候補となる複数の対処を示す場合、該候補となる複数の対処と、該エラーイベントに対して前記モデルを用いて予測された結果とを比較する比較手段と、前記比較の結果、前記候補となる複数の対処と前記予測の結果とが異なる場合、前記履歴から一部の稼動情報を取得し、前記モデルに含まれるそれぞれ異なる予測を行う複数の階層の中の後段の階層に対して、該取得した一部の稼働情報に従う再学習を実行する実行手段と、を有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、ネットワークデバイス内での診断結果を反映した診断モデルの構築が可能となり、故障診断の精度を向上させることが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態を示すシステムの構成図。
【図２】本実施形態におけるハードウェア構成図。
【図３】本実施形態のシステムに係る機能ブロック図。
【図４】本実施形態におけるデバイスデータの蓄積に関する処理のフローチャート。
【図５】本実施形態における診断モデル構築に関する処理のフローチャート。
【図６】本実施形態における故障診断に関する処理のフローチャート。
【図７】本実施形態における診断モデル調整に関する処理のフローチャート。
【図８】本実施形態における診断モデルを説明する図。
【図９】本実施形態における調整中及び調整後の診断モデルを示す図。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について図面を用いて説明する。
〔第１実施形態〕
図１は、本発明の一実施形態を示すシステムの構成の一例を示す図である。
図１に示すように、本実施形態のシステムは、複数のネットワークデバイス（図１の例では画像形成装置102）と、故障診断サービスサーバ101とがネットワーク103を介して通信可能なシステムである。本実施形態では、ネットワークデバイスの例として、プリンタや複合機等の画像形成装置を用いて説明するが、これに限定されるものではない。ネットワークデバイスは、例えばネットワーク接続可能なプロジェクタ、ネットワークカメラ、各種IoT（Internet of Things）機器等のネットワーク接続可能な機器であってもよい。以下、画像形成装置を「デバイス」ともいう。
【００１１】
画像形成装置102は、ネットワーク103を介して、故障診断サービスサーバ101と接続される。
なお、故障診断サービスサーバ101や、故障診断サービスサーバ101を含む故障診断システム100の機能は、１台のコンピュータにより実現されるものであっても、複数のコンピュータにより実現されるものであってもよい。故障診断サービスサーバ101や故障診断システム100の機能は、クラウドサービス等を利用して実現される構成であってもよい。
【００１２】
ネットワーク103は、例えばインターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであってもよい。ネットワーク103は、これらの組み合わせにより実現される、いわゆる通信ネットワークである。
【００１３】
図２（ａ）は、故障診断サービスサーバ101や故障診断システム100を構成する情報処理装置のハードウェア構成の一例を示す図である。これは、一般的な情報処理装置（いわゆるパーソナルコンピュータ（ＰＣ））のハードウェアで構成することができる。
【００１４】
ＣＰＵ201は、ＲＯＭ203内に記憶されたプログラムや、外部メモリ210からＲＡＭ202にロードされたＯＳ（オペレーティングシステム）やアプリケーション等のプログラムを実行することにより、情報処理装置全体を制御する。すなわち、ＣＰＵ201が、読み取り可能な記憶媒体に格納された該プログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。
ＲＡＭ202は、ＣＰＵ201のメインメモリであり、ワークエリア等として機能する。
ＲＯＭ203は、各種プログラムやデータを格納する。
【００１５】
キーボードコントローラ204は、キーボード208や図示しないポインティングデバイス（マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。ディスプレイコントローラ205は、ディスプレイ209の表示を制御する。
ディスクコントローラ206は、各種データを記憶するハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等の外部メモリ210へのデータアクセスを制御する。
ネットワークＩ／Ｆ207はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００１６】
図２（ｂ）は、画像形成装置102のハードウェア構成の一例を示す図である。
画像形成装置102は、例えば、デジタル複合機、ファクシミリ装置、レーザービームプリンタ、インクジェットプリンタ、スキャナ装置などの画像形成装置に適用することができる。
【００１７】
ＣＰＵ221は、ＲＯＭ223に格納されているプログラム（後述する画像形成装置における各処理を実現するプログラムも含む）を備え、内部バス232を介して各デバイスを総括的に制御する。ＲＡＭ222は、ＣＰＵ221のメモリやワークエリアとして機能する。記憶装置224は、外部記憶装置として機能する。ＣＰＵ221は、ＲＡＭ222やＲＯＭ223と共にプログラムの実行処理を行うとともに、記憶装置224等の記録媒体に画像データを記録する処理を行う。記憶装置224は、例えばＨＤＤやＳＳＤやこれらの組み合わせからなる。
【００１８】
ネットワークＩ／Ｆ225は、外部のネットワーク機器と片方向または双方向にデータをやり取りする。
デバイス制御227は、デバイスの各種制御パーツ228を制御する。制御パーツには、例えば印刷部やスキャナなどの画像形成装置の各種機能を実現するための部品郡が存在する。
【００１９】
診断装置229は、画像形成装置102の故障の要因となった箇所を分析して特定するための機器である。診断装置229は、デバイス制御227を介して、各種パーツに電流などを流し、それによって各種制御パーツ228の動作状況を判断し、故障の有無を特定する。
【００２０】
入出力装置231は、画像形成装置102における入出力を担う複数の構成を示す。具体的には、入出力装置231は、ユーザからの入力（ボタン入力など）を受け付け、該入力に対応する信号を入出力Ｉ／Ｆ230によって前述した各処理部へ伝える。他にも、ユーザに対して必要な情報を提供したり、ユーザ操作を受付けたりするための表示装置（タッチパネルなど）も入出力装置231に含まれる。さらに、原稿を読み取り、入力として電子データを受付けるためのスキャン装置も入出力装置231に含まれてもよい。
【００２１】
図３は、本実施形態のシステムに係る機能の一例をする機能ブロック図である。
本実施形態のシステムの機能は、大きく分けて、「デバイスデータの蓄積機能」、「診断モデルの定期的な作成機能」、及び「エラー発生時の故障診断機能」の３つに分けられる。以下、各機能について、図３〜図９を用いて説明する。なお、下記で記載する表のスキーマやデータはあくまで一例であり、表のスキーマや各種データのフォーマットなども実施形態に応じて適宜変形可能である。
【００２２】
なお、図３に示す故障診断サービスサーバ101の各機能部321〜327は、故障診断サービスサーバ101を構成する情報処理装置のＲＯＭ203にプログラムとして格納され、ＲＡＭ202上でＣＰＵ201によって実行されることにより実現される。また、画像形成装置102の各機能部301〜306は、ＲＯＭ223にプログラムとして格納され、ＲＡＭ222上でＣＰＵ221によって実行されることにより実現される。なお、格機能部の説明は、フローチャートの説明とともに説明する。
【００２３】
まず、「デバイスデータの蓄積機能」について、図３及び図４を用いて説明する。
図４は、本実施形態におけるデバイスデータの蓄積に関する処理の一例を示すフローチャートである。このフローチャートに示す処理は、図３に示す画像形成装置102の各機能部及び故障診断サービスサーバ101の各機能部により実行される。
【００２４】
画像形成装置102では、S401において、ジョブ実行部301が、印刷やスキャンなどのジョブを実行する。
次にS402にておい、エラー検知部304が、上記S401に係るジョブ実行中にエラーが発生したか否かを判断する。そして、エラー検知部304が、エラー発生していないと判断した場合（S402でNoの場合）、S406に遷移する。
一方、エラー検知部304が、エラー発生したと判断した場合（S402でYesの場合）、S403に遷移する。
【００２５】
S403では、診断部305が、上記S402で検知されたエラーを引き起こした故障パーツの特定を行う（故障診断）。故障パーツの特定方法としては、例えば、モータの故障を判断する場合には、そのモータに電流を流しモータの回転可否によってそのパーツの故障有無を特定するようなことが考えられる。本実施形態では、上記特定の結果として、下記の表１に示す３パターン（パターンＡ，Ｂ，Ｃ）を想定する。
【００２６】
【表１】
2020009156.tif 000003
【００２７】
パターンＡは、診断部305によって故障している部品が特定できた場合である。故障している部品が複数ある場合にはそれら全てが特定される。
パターンＢは、特定された複数の部品の内、いずれかの部品が故障していることまでしか特定できなかった場合である。例えば、「モータ」、「ケーブル」の２つの部品のうち、いずれか一方が壊れていることまで特定できた場合などが、パターンＢに該当する。
パターンＣは、１つの故障部品（可能性も含む）も特定できなかった場合である。例えば、診断処理ができなかったなどもこのパターンに該当する。
【００２８】
診断部305は、診断結果として、表１に示す故障コードを出力する。表１に示す故障コードは、前３桁の数字で上述の各パターンを示し、後ろ４桁で故障部品を示すことを想定している。
具体的には、前３桁が「001」であるものはパターンＡ、「002」であるものはパターンＢ、「999」であるものはパターンＣであることを示す。
【００２９】
また、後ろ４桁は、例えば「0000」が「基板」、「0001」が「モータ」、「0002」が「ケーブル」であるとする。この場合、パターンＡの行に記載されている故障コードの後ろ４桁は「0000」であるため、「基板」が壊れていることが確定したことを示す。また、パターンＢの行に記載されている故障コードの後ろ４桁は「0000」及び「0001」であるため、「基板」もしくは「ケーブル」のいずれかが故障していることまで特定出来たことを示す。なお、前３桁が「999」のとき（すなわちパターンＣのとき）に限っては、後ろ４桁の数字に意味は持たないものとする。このように、表１に示す故障コードは、画像形成装置102で検出されたエラーイベントに対して行われるべき対処（エラー対処）が特定されたことを示すパターンのコード情報（前３桁）と、対処を示すコード情報（後ろ４桁）を含む。なお、ここでは、エラー対処として、エラーイベントの要因となった箇所を交換する場合を例として、後ろ４桁に、その箇所を特定するコードが記載される例を説明する。しかし、エラー対処として、エラーイベントの要因となった箇所に、交換以外の処置（例えば清掃）を施す場合には、後ろ４桁に、その箇所を清掃することを示すコードが記載されるものとする。また、エラー対処として、特定の操作（「デバイスの再起動」等）を行う場合には、後ろ４桁に、その操作を示すコードが記載されるものとする。さらに、エラー対処はこれらの例に限定されるものではない。
【００３０】
次にS404において、診断結果送信部306は、上記S403での診断結果に基づき、故障データを、故障診断サービスサーバ101に送信する。故障データとしては、上述した故障コード、エラーの内容を示すエラーＩＤ、その発生日時、及び上記S401で実行したジョブを一意に識別するジョブＩＤ等が含まれる。
【００３１】
故障診断サービスサーバ101では、S405において、デバイスデータ受信部321が、上記S404で画像形成装置102から送信された故障データを受信し、デバイスデータ保存部322に、例えば下記の表２のような形で保存する。なお、故障データは、表２に示す情報に限定されるものではなく、その他の情報が含まれていてもよい。
【００３２】
【表２】
2020009156.tif 000004
【００３３】
また、画像形成装置102では、S406において、稼働情報取得部302が、上記S401で実行したジョブのＩＤ、及び、該ジョブの実行によって変化した情報などの各種情報を取得する。なお、ジョブの実行によって変化した情報としては、例えば、デバイスでの総プリント枚数や、デバイス内の温度や湿度、各種パーツ（ドラムや転写ベルト、定着器など）の摩耗度等がある。さらに、稼働情報送信部303は、該取得した各種情報を、稼動データとして、故障診断サービスサーバ101に送信する。
【００３４】
故障診断サービスサーバ101では、S407において、デバイスデータ受信部321が、上記S406で画像形成装置102から送信された稼動データを受信し、デバイスデータ保存部322に、たとえば下記の表３に示すような形で保存する。なお、稼動データは、表３に示す情報に限定されるものではなく、その他の情報が含まれていてもよい。
【００３５】
【表３】
2020009156.tif 000005
【００３６】
以上、図４に示したような処理を行うことで、デバイスの稼働データ、及び故障診断の結果である故障データを、故障診断サービスサーバ101のデバイスデータ保存部322に保存することが可能となる。これにより、デバイスから収集された稼動データ（稼動情報）及び故障データ（エラー対処）の履歴が蓄積される。これにより、故障診断サービスサーバ101では、後述する診断モデルの学習に、これら各種データが利用できるようになる。なお、故障診断サービスサーバ101に保存されたパターンＢやパターンＣに該当する故障データについては、その後、サービスマン等によりエラー対処（故障箇所等）が特定された際には、手動で更新される。その際には、故障コードの前３桁も「001」に更新される。また、本実施形態では、稼動データと故障データとがジョブＩＤで対応付けされているが、他の情報で対応付け可能にしてもよい。例えば、稼動データに日時の情報を含め、日時により稼動データと故障データとを対応付けしてもよい。
【００３７】
次に、「診断モデルの定期的な作成機能」について、図３、図５及び図８を用いて説明する。なお、上述した「デバイスデータの蓄積機能」によって、故障診断サービスサーバ101上には、デバイスのデータがある程度、蓄積保存されているものとする。また、本処理の実行タイミングは、１日に１回や、１週間に１回などの定期的なタイミングで行うことを想定している。
【００３８】
図５は、本実施形態における診断モデル構築に関する処理の一例を示すフローチャートである。このフローチャートに示す処理は、図３に示した故障診断サービスサーバ101の各機能部により実行される。
【００３９】
S501において、診断モデル作成部323は、デバイスデータ保存部322に保存されているデバイス稼働データを取得する。
S502において、診断モデル作成部323は、デバイスデータ保存部322に保存されている故障データを取得する。
【００４０】
次にS503では、診断モデル作成部323は、上記S501及びS502で取得したデータを学習することによって診断モデルを構築する。学習するデータは、パターンＡ（故障箇所が特定されている）の故障データ及び、該故障データと同一のジョブＩＤで対応付けされた稼動データとする。まず、構築される診断モデルの例について説明する。なお、本実施形態では、多層のフィードフォワード型のニューラルネットワーク（Neural Network）を診断モデルの例として記載するが、それ以外のモデルを用いても構わない。ここで、図８を用いて、フィードフォワード型の多層のニューラルネットワークについて説明する。
【００４１】
図８は、本実施形態における診断モデルの一例としてのフィードフォワード型の多層のニューラルネットワークを説明するための図である。まず図８を用いて、その概要について説明する。
図８において記載される「ｘ１」〜「ｘｎ」は、本診断モデルを構築する際の特徴量となる。ここでは、ｎ個の特徴量が存在することを意味する。特徴量としては、上述した表３で述べたようなデバイスの稼働データ（例えばプリント枚数、機内温度、ドラム磨耗度）を用いることが考えられる。なお、ここで構築される診断モデルは、エラー（表２の故障データに含まれるエラーＩＤ）ごとに構築されてもよいし、全てのエラーに共通の診断モデルであってもよい。なお、エラーＩＤごとに診断モデルを構築する場合、あるエラー（エラーＩＤ）が発生した際の稼動データと故障部品の履歴を学習して、そのエラーに対する診断モデルを構築する。また、エラーの種類に関係なく共通の診断モデルで予測する診断モデルを構築する場合、例えば、特徴量に稼動データだけでなくエラーＩＤも含めてもよい。
【００４２】
この診断モデルの目的は、入力層（図中の最左列のノード群）にて、ある特徴量を入力した際に、出力層（図中の最右列のノード群）にて、部品の故障確率を出力することである。出力層に記載される「ｙ１」〜「ｙｋ」は、本診断モデルで出力される部品の故障確率を示す。なお、図中の添字のｋは、故障部品のパターン数となる。
【００４３】
また、図中、ｗ(ａ)ｂｃは、重みであり、診断モデルの構築の際には、ある特徴量を入力した際に、その特徴量に対応する故障部品（特定されているもの）の故障確率が最も高くなるように、この重みを調節する（詳細は後述する）。この重みの調節を、診断モデルの学習と呼ぶ。
【００４４】
重みｗ(ａ)ｂｃにおける各添字の意味を説明する。
ａは、多層ニューラルネットワークにおけるａ層目の重みであることを示す。ｂは、入力元のノード（図中の丸で示される単位）を示す。ｃは、出力先のノードを示す。
【００４５】
図中、ｕｊｋの添字であるｊ及びｋは、ｊ層目のｋ番目のノードであることを示している。ｕｊｋは、以下に示す式（１）によって求めることができる。
【００４６】
【数１】
2020009156.tif 000006
【００４７】
次に、ｚｊｋは、ｕｊｋに対して活性化関数を適応した結果の値である。活性化関数としては、正規化線形関数（ReLU）「f(u) = max(u,0)」などが有名である。
【００４８】
最後に、出力層（図中、最右列のノード郡）について説明する。
今回の目的は、特徴量を入力した際に、複数ある部品の中で壊れている可能性が最も高い部品を出力することであるため、一般的には多クラス分類と呼ばれる分野にマッチすると考えられる。そこで、本実施形態においては、出力層の活性化関数としてソフトマックス関数を選択し、ｋ番目のノードの出力値ｙｋを以下に示す式（２）によって算出することとする。
【００４９】
【数２】
2020009156.tif 000007
【００５０】
ｙｋの値は、擬似的に確率とみなすことができ、本実施形態では、この値が最も大きくなるノードに対応する部品を故障部品として診断する。
上述したように、重みの学習の際には、ある特徴量を入力した際に、その特徴量に対応する故障部品（特定されているもの）に対応するノードの出力値が最も高くなるように学習する。具体的には、特徴量を入力として出力される値ｙｋが示す部品と、その特徴量に対応して実際に故障していた故障部品（＝正解データ）との誤差を交差エントロピーによって求め、その誤差が最も小さくなるように、誤差逆伝搬法などを用いて、重みを調整する。本実施形態の場合は、特徴量ｕｉとして入力した稼動データに対して出力される値ｙｋが示す部品と、その稼動データと同一のジョブＩＤに紐付けられた故障データで故障と特定されている部品（＝正解データ）との誤差が最も小さくなるように重みを調整する。これらの処理を行うことで、フィードフォワード型の多層のニューラルネットワークを構築する。
【００５１】
なお、図中で入力層、および出力層を除いた部分を中間層と呼ぶこととする。また、一般に多層のニューラルネットワーク（いわゆるDeep Learning）を構築する際には、自己符号化や汎化性能を高めるためのドロップオフなどの設定を行うことが多い。それらの説明は割愛するが、本実施形態においても、それらのアルゴリズムを適用してもよい。なお、中間層の層数や、ドロップオフ率等の各種ハイパーパラメータは、予め実験的に求めておくものとする。以上で説明したように、本ステップにおいては保存された稼働データや故障データなどを基に、重みを学習し、診断モデルを構築する。
【００５２】
以下、図５の説明に戻る。
S504において、診断モデル作成部323は、上記S503で学習された重みの値を、診断モデル保存部324に保存し、本フローチャートの処理を終了する。
以上、図５のフローチャートに示す処理を行うことで、デバイスの稼働データをもとに故障している部品を提示可能な診断モデルを構築することが可能となる。これにより、故障診断サービスサーバ101に、上述のように作成された診断モデルが保持される。
【００５３】
最後に、「エラー発生時の故障診断機能」について、図３、図６、図７及び図９を用いて説明する。なお、上述した「診断モデルの定期的な作成機能」によって、診断モデルが構築されているものとする。
図６は、本実施形態における故障診断に関する処理の一例を示すフローチャートである。このフローチャートに示す処理は、図３に示す画像形成装置102の各機能部及び故障診断サービスサーバ101の各機能部により実行される。なお、図６のフローチャートでは、エラーが発生する場合のみを記載しているため、図４のフローチャートで示した故障データ及び稼働データ送信処理から一部簡略化して記載している。
【００５４】
画像形成装置102では、S601において、エラー検知部304がエラーを検知すると、S602において、診断部305が、図４の説明にて述べたように、故障部品を特定し、故障コードを求める。
次にS603において、診断結果送信部306は、上記S602で求めた故障コードを含む故障データ、及び、その際の稼働データを故障診断サービスサーバ101に送信する。なお、S601〜S603は簡略化して記載したものであり、図４のS402、S403、S404及びS406の処理と同様の処理を示す。
【００５５】
故障診断サービスサーバ101では、S604において、デバイスデータ受信部321が、故障コードを含む故障データ及び稼働データを受信し、デバイスデータ保存部322に保存する。なお、S604は簡略化して記載したものであり、図４のS405及びS407の処理と同様の処理を示す。
【００５６】
次にS605において、診断部325は、上記S604で受信した故障コードのパターンを確認し、パターンＡ（故障部品が特定可能）であるか否かを判定する。そして、パターンＡ（故障部品が特定可能）と判定した場合（S605でYesの場合）、S606に遷移する。
S606において、診断結果通知部326は、受信した故障コードによって表現される部品（故障箇所）を提示する（例えばブラウザに表示したり、連携システム先に通知したりする）。
【００５７】
一方、上記S605において、診断部325が、上記S604で受信した故障コードのパターンがパターンＡ（故障部品が特定可能）でないと判定した場合（S605でNoの場合）、S607に遷移する。すなわち、故障可能性のある部品が複数存在（故障コードがパターンＢ）、もしくは、１つの故障部品（可能性も含む）も特定できなかった（故障コードがパターンＣ））の場合、S607に遷移する。
【００５８】
S607において、診断部325は、診断モデル保存部324より、学習された診断モデル（重み）を取得し、上記S603で受信した稼働データに対して適応し、最も故障確率が高い部品を求める（予測する）。例えば、下記の表４に示すような値が診断モデルより出力されたとする。
【００５９】
【表４】
2020009156.tif 000008
【００６０】
表４に示す例の場合、「基板」に対する出力値が最も高いため、「基板」が故障部品であると診断する。
次にS608において、診断部325は、上記S604で受信した故障コードのパターンがパターンＣ、又は、上記S607によって故障箇所と予測された故障部品が上記S603で受信した故障コードによって表される故障部品に含まれる、か否かを判定する。なお、パターンＣは、１つの故障部品（可能性も含む）も特定できなかった場合である。
【００６１】
そして、パターンＣ、又は、予測された故障部品が受信した故障コードによって表される故障部品に含まれている、と判定した場合（S608でYesの場合）、S609に遷移する。
一方、パターンＣでなくパターンＢ、且つ、予測された故障部品が受信した故障コードによって表される故障部品に含まれない、と判定した場合（S608でNoの場合）、S610に遷移し、図７にて後述する処理を実施するように制御する。なお、パターンＢは、故障可能性のある部品が複数存在する場合であり、この場合、故障コードには故障可能性のある部品を表すコードが含まれる。
【００６２】
ここで、上記S608の分岐処理の意味を簡単に説明する。
サーバ上で構築された診断モデルの構築アルゴリズムの背景には統計的な考え方が存在する。つまり、過去のデータから判断した場合に、確率的に故障している確率が最も高いのであって、今発生したエラーに対して提示される故障部品が、100％の確率で故障しているとは言うことはできない。一方、画像形成装置102から送信される故障コードが表す故障部品は、ハードウェア的に動作しないこと確認した上で、故障したと判断された部品の候補であるため、複数の故障コードが示す部品のいずれかは、ほぼ100％の確率で故障したと断定できる。そこで、ハードウェア的に求められた故障部品と、診断モデルによって求められた故障部品が異なる場合に限り、図７にて後述する処理を実施し、ハードウェア的に求められた故障部品に予測結果が合うように、診断モデルを調整する。
【００６３】
S609において、診断結果通知部326は、診断モデルによって求められた最も故障確率の高い部品（故障箇所）を提示する（例えばブラウザに表示したり、連携システム先に通知したりする）。
【００６４】
また、S610において、診断モデル調整部327は、診断モデルを調整する。S610の診断モデル調整処理（再学習）については、図７を用いて後述する。
次にS611において、診断部325は、上記S610にて診断モデル調整部327が調整した診断モデルを用いて、故障部品を診断する。診断結果などは、表４で説明したものと同じように、各部品に対して、故障確率が出力される。そして、S609において、診断結果通知部326は、診断モデルによって求められた最も故障確率の高い部品（故障箇所）を提示する。
【００６５】
最後に、図７及び図９を用いて、図６のS610の診断モデル調整処理の詳細について説明する。
図７は、第１実施形態における診断モデル調整に関する処理（診断モデル調整処理）の一例を示すフローチャートである。このフローチャートに示す処理は、図３に示す故障診断サービスサーバ101の診断モデル調整部327により実行される。
また、図９は、第１実施形態における調整中及び調整後の診断モデルの一例を示す図である。
【００６６】
S701において、診断モデル調整部327は、診断モデル保存部324より、前述した中間層の重み（ｗ(ａ)ｂｃ）を取得し、該重みによって表現されるニューラルネットワーク（すなわち調整中のニューラルネットワーク）を構築する。このときのニューラルネットワークは、図９（ａ）にて表現するように、図８にて説明したニューラルネットワークの最終層を除いたものと同じものとなる。
【００６７】
次にS702において、診断モデル調整部327は、今回受信した故障可能性のある故障コード（図６のS604で受信）によって表現されるパーツ（故障パーツの候補）のみを出力するように、ニューラルネットワークの出力層（最後段の階層）を設計（調整）する。この設計されたニューラルネットワーク（すなわち調整後のニューラルネットワーク）の例を図９（ｂ）に示す。
【００６８】
以下、ニューラルネットワークの調整について具体例を用いて説明する。
例えば、図６のS604で受信した故障コードが「002-0000」及び「002-0001」の２つである場合を仮定する。つまり、表１や表２の説明で述べたように、「基板」もしくは「ケーブル」のいずれかが壊れている可能性（すなわち故障箇所の候補）をデバイスから通知されたとする。そこで、図９（ｂ）に示すように、出力層のノードとして「基板」と「ケーブル」に対応する２つ（ｙ１、ｙ２）のみを用意する。次に、学習データとして、それら２つのいずれかが実際に故障していた（特定済みの）故障データ、及びそれに対応する（ジョブＩＤで対応付けされている）稼働データを診断モデル保存部324から取得し、そのデータを学習する。この学習する際には、中間層の最後のノードからそれら２のノードへの新たな重みのみ（図中、new_ｗ(Ｌ)１１，new_ｗ(Ｌ)１２、・・・、new_ｗ(Ｌ)ｋ１，new_ｗ(Ｌ)ｋ２）を学習する。
【００６９】
ここで、本ステップにおいて行う最終層の重みのみの学習が意味することを簡単に説明しておく。
一般に多層のニューラルネットワークにおいては、特に自己符号化などを行った場合、入力の特徴量を適切に表現する特徴が中間層にて抽出されると言われている。画像認識系のニューラルネットワークでは、その傾向が顕著である。例えば、最初の方の層の重みは、直線や点などの非常に簡単な特徴のみを抽出する重みが計算されるのに対して、後ろに行くに従ってより高度（折れ線や、折れ線を組み合わせた図形）などを抽出できる重みが求められるとされる。転移学習と呼ばれる技術においては、この多層ニューラルネットワークの特徴を活かし、一度学習した中間層を再利用し、少ない計算コストで、精度の高い診断モデルを作ることができる。また、多層のニューラルネットワークの学習の場合、学習する重みが多いことから、非常に多くの計算時間が必要となるが、今回示したような最終層のみであれば、計算時間の短縮も可能となる。
【００７０】
以上、第１実施形態に係る故障診断のためのシステムを構築することにより、デバイスの診断結果を反映した診断モデルの構築が可能となり、故障診断の精度を向上させることが可能となる。
なお、上記実施形態では、図６のS604で受信した故障コードのパターンがパターンＡ（故障部品が特定可能）と判定した場合（S605でYesの場合）、特定された障害部品とモデルを用いた予測結果との比較を行わない構成を示した。しかし、この場合にも、特定された障害部品とモデルを用いた予測結果との比較を行い（S607、S608）、異なる場合には、診断モデルを調整し（S610）、調整後のモデルを用いた予測（S611）を行うように構成してもよい。
【００７１】
〔第２実施形態〕
以下、第１実施形態と異なる点についてのみ説明し、同一の点については省略する。上述した第１実施形態では、診断部325が出力する値（ソフトマックス関数による擬似的な確率）を基に、最も確率が高い部品を、故障部品を提示する構成について示した。
【００７２】
しかし、前述したソフトマックス関数の式から明らかなように、それぞれの部品の故障確率が「０」〜「１」の間で算出されるわけではなく、全ての出力値の総和が「１」となるように出力が正規化されている。例えば、画像形成装置102からの故障コードが示す故障部品が３つあった場合に、出力値が以下の表５に示すようなパターンになり得る。
【００７３】
【表５】
2020009156.tif 000009
【００７４】
この場合、最も確率が高い故障部品は「基板」で確率値が「0.45」である。このため、第１実施形態の場合、「基板」のみが故障部品として提示されることとなる。しかし、複数の部品が壊れている可能性もある。また、「ケーブル」の確率値は「0.43」であり、確率値も「基板」と「ケーブル」で値がほぼ同じである。このため、故障部品として複数提示することも必要であると考えられる。
【００７５】
そこで、第２実施形態においては、診断部325が診断結果を提示する際に、最も出力値が高いものだけではなく、最も出力値が高いものからの差が、所定のしきい値以内の出力値となる部品についても故障部品として提示することとする。なお、本実施形態における「しきい値」は予め静的に定められた値を用いることとする。また、この「しきい値」は管理者等により変更可能としてもよい。
その他の構成については、第１実施形態で述べたものと同じであるため、説明を割愛する。
以上、第２実施形態で述べた方法に従って処理をすることにより、複数の故障部品の提示も可能となる。
【００７６】
以上のように、デバイス側のハードウェアによる故障診断と、機械学習などの手法を組み合わせて機器の故障診断を組み合わせる場合、ハードウェアによる故障診断の結果の方が、診断結果の精度が高い場合多い。ハードウェアによる故障診断の結果と、機械学習による故障診断の結果が異なる場合に、それらの結果を独立したものとして扱っていては、精度の高い故障診断が難しい。そこで、ハードウェアによる故障診断と、機械学習による故障診断の結果が異なる場合には、ハードウェアによる故障診断の結果を用いて、機械学習による故障診断を行うためのモデルを調整する。これにより、デバイスの診断結果を反映した診断モデルの構築が可能となり、故障診断の精度を向上させることができる。
【００７７】
以上示したように、各実施形態では、デバイスによる故障診断結果と、過去の実績を基にサーバ上で構築した診断モデルよる診断結果が異なる場合には、サーバ側のモデルを調整し、デバイスから得られた信号の組み合わせの中で、故障箇所を診断する。この構成により、デバイス内での診断結果を反映した診断モデルの構築が可能となり、故障診断の精度を向上させることが可能となる。
【００７８】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施形態を組み合わせた構成も全て本発明に含まれるものである。
【００７９】
（その他の実施形態）
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図１】
2020009156.tif 000010
【図２】
2020009156.tif 000011
【図３】
2020009156.tif 000012
【図４】
2020009156.tif 000013
【図５】
2020009156.tif 000014
【図６】
2020009156.tif 000015
【図７】
2020009156.tif 000016
【図８】
2020009156.tif 000017
【図９】
2020009156.tif 000018