JP5370905B2 - 故障診断装置およびプログラム - Google Patents

Description

本発明は、故障診断装置、並びに電子計算機（コンピュータ）を用いて故障診断を実現するためのプログラムに関する。

近年、各種の機械、たとえば、複写機あるいはプリンタなどのオフィス機器においては、高い生産性が要求されるため故障による遅滞が許容されず、故障を速やかに検知して解決することが求められている。また、自動車や航空、ロボットや半導体設計装置など、他の産業機器においても動作制御などの手段として、信頼性が高く、高速・高精度での動作が可能な部材が数多く搭載されているため、一般的に故障発生の頻度が高い。特に使用環境が劣悪である場合には、通常の方法で使用していたとしても、検出が困難な様々な異常や故障が発生し、その修復には多大な労力を要することになる。これらの対処として、故障診断を自動的に行なう仕組みが考えられている（たとえば特許文献１〜３を参照）。たとえば、規則に基づくシステム（ルール型システム）を使用して、自動診断を行なう仕組みが考えられている。ルール型システムの一例としては、ベイジアンネットワーク（Bayesian Network）を利用した故障診断システムがある。

特開２００３−０３２２５３号公報 特開２００１−０７５８０８号公報 特表２００５−５２７００８号公報

たとえば、特許文献１に記載の仕組みでは、通信ネットワークで障害診断をする手法を採っている。具体的には、システムからのアラームに応答して因果ネットワークを構成して、障害につながった可能性がある１つまたは複数のモジュールの誤動作と障害を関連付け、誤動作のそれぞれの確率に障害の条件付確率を関連付けておき、アラームおよび因果ネットワークに基づいて、誤動作の少なくとも１つを更新する、アラームの診断を更新された確率に応答して提示する。

特許文献２に記載の仕組みでは、システムのトラブルシューティングを行なう自動トラブルシューティング機構として、ベイジアンネットワークを使用し、原因確率の評価やアクションおよび質問セットについての確率の評価を行ない、最も問題解決確率が高くコストの低いアクションを順次ユーザに提案するようにしている。

特許文献３に記載の仕組みでは、１つまたは複数の処理デバイス上で動作するコンポーネントベースソフトウェアシステムのランタイム監視を実現するために、コンポーネント開始時にスタブ開始ログを取得し、終了時にスタブ終了ログを取得することで、このログを元にタイミング待ち時間・共有資源使用量・因果関係などの監視を行なうようにしている。

本発明は、ソフトウェア環境の変化が起きたときに、迅速あるいは容易に、その変化状況を診断モデルに反映することのできる仕組みを提供することを目的とする。

請求項１に記載の発明は、電子機器を動作させるソフトウェアの処理履歴を記録する記録手段と、前記電子機器に前記ソフトウェア処理を起因とする障害が発生したときに、前記障害の発生以前における前記ソフトウェアの処理履歴を前記記録手段から取得する取得手段と、前記取得手段により取得された前記処理履歴に基づいて、前記ソフトウェア処理を起因とする障害の１つまたは複数の原因モジュールに分類する分類手段と、前記分類手段により分類された原因モジュールのそれぞれを確率で関連付けたサブ因果ネットワークを生成する生成手段と、前記生成手段により生成されたサブ因果ネットワークを、既存の診断モデルの因果ネットワークに組み込んで前記既存の診断モデルを更新する更新手段とを有する故障診断装置である。

請求項２に記載の発明は、請求項１に記載の発明においてさらに、前記取得手段は、前記ソフトウェアの処理履歴として、前記障害の発生を通知したソフトウェアモジュールの関数の呼出しスタックを遡って出力したバックトレースログを取得し、前記取得手段が取得したバックトレースログから呼出し関数およびこの呼出し関数が含まれるソフトウェアモジュールを抽出し、呼出し関数およびソフトウェアモジュールの単位でグラフ化することで呼出し関数グラフを生成する呼出し関数グラフ生成部をさらに備え、前記生成手段は、前記関数グラフ生成部により生成された呼出し関数グラフのソフトウェアモジュールを前記サブ因果ネットワークのノードに割り当てるとともに、前記呼出し関数をそのノードのステートに割り当て、各ノードを呼出し関数の読出し順に基づいてリンクすることで前記サブ因果ネットワークを生成する。

請求項３に記載の発明は、請求項２に記載の発明においてさらに、前記更新手段は、前記サブ因果ネットワーク生成部が生成したサブ因果ネットワークを既存の診断モデルの因果ネットワークと組み合わせるに当たり、既存の診断モデルの因果ネットワークに対して、前記サブ因果ネットワーク生成部が生成したサブ因果ネットワークのノード名とリンクを検索し、前記サブ因果ネットワークのノードが既存の診断モデルに存在するときにはステートの追加や確率値の更新を行ない、前記サブ因果ネットワークのノードが既存の診断モデルに存在しないときには、ノード，リンク，確率テーブルを追加する。

請求項４に記載の発明は、請求項１に記載の発明においてさらに、前記取得手段は、前記ソフトウェアの処理履歴として、ソフトウェア処理システムのプロセスログを取得し、前記生成手段は、前記取得手段により取得されたプロセスログ中のプロセスリストを原因とし、前記障害の発生を結果とすることで、前記サブ因果ネットワークを生成する。

請求項４に記載の発明は、請求項１に記載の発明においてさらに、前記生成手段により生成されたサブ因果ネットワークを保存するサブ因果ネットワーク保持部と、複数の電子機器の各サブ因果ネットワーク保持部に保持されているサブ因果ネットワークを所定のタイミングで収集するサブ因果ネットワーク収集部とをさらに備え、前記更新手段は、前記サブ因果ネットワーク収集部が収集した各電子機器のサブ因果ネットワークを機種ごとに分類して、機種別に既存の診断モデルに組み込む。

請求項６に記載の発明は、故障診断用の診断モデルを、電子計算機を用いて用意するためのプログラムであって、前記電子計算機に、電子機器を動作させるソフトウェアの処理履歴を記録する記録手段と、前記電子機器に前記したソフトウェア処理を起因とする障害が発生したときに、前記障害の発生以前における前記ソフトウェアの処理履歴を前記記録手段から取得する取得手順と、前記取得手段により取得された前記処理履歴に基づいて、前記ソフトウェア処理を起因とする障害の１つまたは複数の原因モジュールに分類する分類手順と、前記分類手段により分類された原因モジュールのそれぞれを確率で関連付けたサブ因果ネットワークを生成する生成手順と、前記生成手段により生成されたサブ因果ネットワークを、既存の診断モデルの因果ネットワークに組み込んで前記既存の診断モデルを更新する更新手順とを実行させるプログラムである。

請求項１に記載の発明によれば、ソフトウェア環境の変化が起きたときに、迅速あるいは容易に、その変化状況を診断モデルに反映することができる。その結果、ソフトウェア障害の故障診断の診断性能が向上する。

請求項２に記載の発明によれば、バックトレースログを利用して、発生したソフトウェアの障害に帰結するソフトウェア内部の因果関係を、迅速あるいは容易に診断モデルに反映することができる。その結果、ソフトウェア障害の故障診断の診断性能が向上する。

請求項３に記載の発明によれば、既存のノードとの関係での障害発生に対する反映だけでなく、新規ノードの追加により障害発生に対する反映も可能となる。これにより、たとえば、実稼動中に開発者が想定していないランタイムエラーや、外部ベンダが作成し新規にインストールしたソフトウェアとの干渉によるエラーなどが生じた場合でも、迅速かつ容易に診断モデルに反映することが可能となる。

請求項４に記載の発明によれば、プロセスログをソフトウェアの処理過程の記録として利用することで、特定のソフトウェアだけでなく同時に起動されている他の複数ソフトウェアとの因果関係を診断モデルに反映することができる。すなわち、プロセスログ中のプロセスリストを原因とし障害の発生を結果とすることでサブ因果ネットワークを生成できるので診断モデルの適正化が容易で迅速にできる。

請求項５に記載の発明によれば、複数の電子機器のサブ因果ネットワークを収集して纏めて診断モデルに組み込むことができるので、各電子機器で個別に保持している障害情報を網羅した診断モデルを生成することが可能になり、診断精度がさらに向上する。

請求項６に記載の発明によれば、ソフトウェア環境の変化が起きたときに、迅速あるいは容易に、その変化状況を診断モデルに反映することで、ソフトウェア障害の故障診断の診断性能を向上させる仕組みを、電子計算機を用いて実現できる。

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

＜＜画像形成装置の構成例＞＞
図１は、故障診断装置の一実施形態を搭載した画像形成装置の構成例を示す図である。ここで、図１は、画像形成装置１の故障診断機能に着目した機能ブロック図である。

画像形成装置１は、たとえば原稿の画像を読み取る画像読取部（スキャナ部）を備え、画像読取部で読み取った画像データに基づいて原稿画像に対応する画像を印刷する複写装置機能、パソコンなどから入力された印刷データ（画像を表すデータ）に基づいて印刷出力するプリンタ機能、およびファクシミリ画像を印刷出力可能なファクシミリ送受信機能を備えた複合機であって、デジタルプリント装置として構成されているものである。

図１に示すように、本実施形態の画像形成装置１は、故障診断機能に関わる機能部として、当該画像形成装置１の故障（特にソフトウェア障害）を診断する故障診断装置３（故障診断部）と、用紙通過時間、駆動電流、装置内部温湿度などの装置を診断するために必要となる、装置が動作しているときの装置内部の状態情報（動作状態信号）を観測データとして自動的に取得するセンサ部４と、故障診断に必要な情報を入力するための故障診断入力部５を備える。また、画像形成装置１は、その基本機能をなす機能部として、画像を形成し出力する画像形成部６と、原稿画像を読み込む画像読取部７と、通信網４０６（ネットワーク）を介して各種の情報のやり取りを行なう通信部８を備える。故障診断装置３は、必要に応じて、管理センタ４０１に備えられる管理装置（たとえばホストコンピュータ）と連携した処理を行なうように構成してもよい。

ソフトウェア障害の故障診断を行なうに当たって、センサ部４は、ソフトウェア障害を起因とする搬送系の異常（たとえばジャムの発生や搬送タイミングのずれなど）や画像系の異常（たとえば線・帯欠陥や白抜けや黒点色点などの発生）を検知して障害の発生の通知を出力する際の予備的手段として利用するようになっている。センサ部４を利用した障害の検知手法を採り、その障害（故障）が発生するまでのプログラムの進行状態のログを辿る仕組みと関連付けるようにする。

ここで、センサ部４で検知した障害は画像形成装置１の動作に深刻な影響を及ぼすレベルをエラー、現段階では影響を及ぼさないがいずれ影響する警告レベルをワーニングとして定義する。エラーの例としては、たとえばディスクへの書き込みエラーが発生した際にその旨を出力する場合があり、ワーニングの例としては、たとえばトナーの残量が少ないことを検知した際にその旨を出力する場合がある。エラーやワーニングは、画像形成装置１上で動作しているスキャンやプリントなどのアプリケーションソフトウェアやＯＳから発せられるものであり、センサの検知状況に応じたメッセージ出力コードをアプリケーションソフトウェアに記述することで実現している。また、ＯＳのカーネル内に予め記述されている障害検知報知機能で実現している。

画像形成部６は、画像読取部７で読み込んだ画像または通信部８を介して各種の情報機器からプリント指示された画像を所定の印刷用紙上に出力する。なお、通信部８は、通信部８が通信部８を介して管理センタ４０１に備えられる管理装置から最新の診断モデルを取得するためにも利用される。

故障診断装置３は、各取得情報に基づき、画像形成装置１に発生したソフトウェア障害の故障診断を行なうのに必要な情報を生成する診断情報生成部３Ａと、診断情報生成部３Ａより得られた情報に基づいて故障診断を行なう故障診断部３Ｂを有する。

＜故障診断装置＞
図２は、故障診断装置３の一実施形態を示すブロック図である。故障診断装置３は、ソフトウェア処理で各種の処理を行なうように構成されている診断対象装置（前例では画像形成装置１）にてソフトウェア障害を起因とするエラーやワーニングが起きたときに、ソフトウェア処理の履歴（ログ）を参照して故障診断を行なうように構成されている。

たとえば、故障診断装置３の診断情報生成部３Ａは、センサ部４で取得された観測データやその他の故障診断に必要な各種情報を取得する動作状態情報取得部１４０と、発生した故障の状態を故障診断入力部５により提示された画面の指示に従ってユーザが入力することにより得られた故障情報を取得する故障情報取得部１５２と、ユーザ操作によって動作条件の異なる状態で故障情報を取得する追加操作情報取得部１５４と、診断情報収集部１６０（特徴量抽出部）を備えている。

動作状態情報取得部１４０は、センサ部４より取得された各部品の稼動状態を示す部品情報を観測データ情報として取得する部品状態情報取得部１４２と、画像形成装置１の使用状況を監視するとともに、監視結果を不揮発性の記憶媒体に登録・保持することで画像形成装置１の使用状況の監視結果を履歴情報として管理する履歴情報取得管理部１４３を有する。

さらに動作状態情報取得部１４０は、センサ部４をなす稼働温度検出部８４や稼働湿度検出部８６にて検知される情報に基づき、温度や湿度などのコンポーネントの状態に影響を与える周囲環境条件を環境情報として取得する環境情報取得部１４４と、消耗材検知部（用紙情報収集部８８や色剤残量検知部８９など）にて検知される情報に基づき、印刷用紙の厚さや用紙種別、あるいは色剤の色種やタイプや残量など装置が使用する消耗材の情報を取得する消耗材情報取得部１４５と、画像形成装置１の仕様情報を取得する仕様情報取得部１４６を有する。

診断情報収集部１６０は、部品状態情報取得部１４２にて取得される搬送系の駆動部材が所定期間動作している間の動作状態を示す動作状態信号に基づいて、その動作状態信号の特徴量を求める。また、診断情報収集部１６０は、部品状態情報取得部１４２だけでなく、履歴情報取得管理部１４３、環境情報取得部１４４、消耗材情報取得部１４５、あるいは仕様情報取得部１４６からの情報も取得して、それら取得した情報の特徴量も求める。診断情報収集部１６０は、部品状態情報取得部１４２からの動作状態信号やその他の履歴情報取得管理部１４３などからの情報を受け取る動作状態信号受取部の機能を持つ。

診断情報収集部１６０は、ソフトウェア障害を起因とする搬送系の異常（たとえばジャムの発生や搬送タイミングのずれなど）や画像系の異常（たとえば線・帯欠陥や白抜けや黒点色点などの発生）をセンサ部４により検出される観測データを監視し、それが所定の閾値に対して正常範囲外になったときエラーやワーニングを出力するようになっている。

また、診断情報生成部３Ａは、ソフトウェア障害を起因とする故障の診断を行なうための特徴的な機能要素として、ソフトウェア処理のログ（処理過程）を記録するレジスタなどのログ記録部１６８（処理過程記録部の一例）を有する。

故障診断装置３の故障診断部３Ｂは、故障診断時の判定指標となる基準特徴量や故障診断条件（故障診断モデルなど）を所定の記憶媒体（好ましくは不揮発性の半導体メモリ）に格納する判定指標格納部２３０、各取得部（動作状態情報取得部１４０、故障情報取得部１５２、追加操作情報取得部１５４）より得られた情報に基づいて故障原因の確率を算出する故障確率推論部２６０（診断実行部）、あるいは故障判定結果や検査内容をカスタマに通知する通知部２７０などを内部に有する。故障確率推論部２６０は、故障候補抽出や故障判定や故障予測を行なう故障判定部２６２と、故障判定部２６２の故障判定や故障予測に際して使用される故障確率を推論する推論エンジン２６４を有する。

また、故障診断部３Ｂは、ソフトウェア障害を起因とする故障の診断を行なうための特徴的な機能要素として、故障診断条件の適正化処理を行なう診断条件制御部４６０（更新制御部）を備えている。故障診断モデルなどの故障診断条件を画像形成装置１自身で生成して用意するか管理センタ４０１側で生成して画像形成装置１に送るかを問わず、診断条件制御部４６０は、ソフトウェア障害を起因とする故障が発生したとき、エラーやワーニングをトリガとしてソフトウェアログを取得し、このソフトウェアログに基づきサブ因果ネットワークを生成し、このサブ因果ネットワークを既存の診断モデルに組み込むことで診断モデルを更新することにより、ソフトウェア障害を起因とする故障の診断性能を向上させることが好ましい。診断条件制御部４６０を構成する各機能部については後で詳しく説明する。

なお図示しないが、判定指標格納部２３０には、記憶媒体の他に、記憶媒体に基準特徴量を書き込むための書込制御部や、記憶された基準特徴量を記憶媒体から読み出すための読出制御部が設けられる。記憶媒体は、画像形成装置１において診断情報収集部１６０によって取得される種々の動作状態信号の履歴情報を保持する履歴記憶部の機能を持つ。

基準特徴量としては、たとえば、駆動機構部を構成する機構部材（モータやソレノイドなどの駆動部材を含む）や機構部材を駆動する電気部材（駆動信号生成部１５０や駆動回路）が正常に動作している正常状態で、診断情報収集部１６０により取得された特徴量（たとえば分布状態を特定する情報など）を使用する。あるいは、診断情報収集部１６０で得られる特徴量に代えて、画像形成装置１におけるステッピングモータなどの動作電流や振動の定格値を利用してもよい。また、故障が検知された場合に、その故障箇所や故障状態を判定するための基準特徴量として、各構成部材が故障時に、診断情報収集部１６０により取得された特徴量（たとえば分布状態を特定する情報など）を使用する。記憶媒体に記憶される故障状態に関する基準特徴量は当該画像形成装置１の診断モデルとして利用されるもので、たとえば当該装置の各部材を強制的に故障状態にして診断情報収集部１６０により検知したものであってもよいし、管理センタ４０１などに集約されるメンテナンス情報に基づいて取得した情報を用いてもよい。

なお、故障診断装置３を構成する各部（診断情報生成部３Ａや故障診断部３Ｂ）はそれらが１つの画像形成装置１に搭載された形態に限らず、それらを構成する機能部の一部あるいは全部が画像形成装置１とは別の装置に搭載された形態（いわゆるシステム構成）であってもよい。たとえば、診断情報収集部１６０を画像形成装置１側の故障診断装置３から取り外して管理センタ４０１側に診断情報取得部を配置し、センサ部４で取得される情報を管理センタ４０１側の診断情報収集部１６０に送り、管理センタ４０１側にて特徴量を特定して診断モデルを用意するようにしてもよい。この際には、当該装置だけでなく、同種装置の複数台の情報から共通の診断モデルを生成することを基本とし、必要に応じてさらに当該装置に固有の情報に基づき前記共通の診断モデルを修正して当該装置用の診断モデルとして使用するなどするのがよい。

故障判定部２６２は、記憶媒体に格納しておいた診断モデル（自装置で取得した基準特徴量を含む）と故障診断時に診断情報収集部１６０で得られる特徴量である実働特徴量とを比較することにより、診断対象ブロックに故障が発生しているか否かや、将来故障が生じる可能性など故障に関わる診断処理を行なう。

たとえば故障確率推論部２６０は、各画像形成装置１についての故障情報の収集や診断モデルの更新などを行なう管理センタ４０１（データセンタとも称する）と接続され、管理センタ４０１に配置されたデータベースDBに故障情報や診断モデルを登録したり、データベースDBに登録されている各種の診断モデルの中から診断対象の画像形成装置１に適した診断モデルの選択・提供を受けたりして故障診断を行なう。

たとえば、故障確率推論部２６０は、画像形成装置１を構成するコンポーネントの状態情報、装置の履歴情報、装置が設置されている周辺環境情報、およびユーザ操作によって得られる追試結果情報を用いて前記画質欠陥を引き起こす原因となる箇所の故障確率を推論エンジン２６４にて推論し、推論エンジン２６４にて算出した故障確率を元にして故障判定部２６２にて故障箇所の候補を抽出する。

故障判定部２６２は、推論エンジン２６４を利用して故障候補を絞り込む故障候補抽出部の機能を有しており、絞り込んだ故障候補、故障判定結果（故障の有無、故障箇所、故障内容）、故障予測結果（故障可能性の有無、故障箇所、故障内容）、あるいは検査内容や取得した動作状態信号などを通知部２７０に通知する。

ここで、自動判定処理を行なったときに、故障箇所候補を絞りきれないときには、ユーザ操作によって得られた動作条件の異なる状態で取得された追試結果情報の入力を待って、推論エンジン２６４にて故障確率を再計算し、それぞれの動作条件で取得される故障確率に基づいて、より適切な故障箇所を抽出する。

通知部２７０は、たとえば、故障判定部２６２から受け取った故障判定結果などを、お客様（画像形成装置１の操作者や所有者）、画像形成装置１をメンテナンス（保守、維持、管理）するカスタマーエンジニア、あるいは画像形成装置１を管理している管理センタ４０１などのカスタマーエンジニアやカスタマーに通知する。

たとえば、お客様に直接知らせる場合は、画像形成装置１にアラームを知らせるような、たとえば表示パネルやスピーカなどで知らせる。お客様は、それを見てあるいは聞いて、故障箇所や故障内容をサービスセンタに知らせる。また、画像形成装置１をメンテナンスするカスタマーエンジニアに直接知らせる場合は、公衆電話回線や、ＰＤＡ（Personal Digital Assistant）、携帯電話、ＰＨＳ（Personal Handy-phone System ）などの携帯端末を使って、故障発生などを連絡する。また、故障箇所や故障内容のデータをカスタマーエンジニアが所有する端末に送るようにしてもよい。

また、画像形成装置１を管理している管理センタ４０１などに知らせる場合は、カスタマーエンジニアに直接知らせる場合と同様に、公衆電話回線や携帯端末を使うようにしてもよい。また、インターネットを利用した連絡を行なうようにしてもよい。これらの場合も、故障箇所や故障内容のデータを管理センタ４０１の端末に送るようにしてもよい。

ところで、故障診断装置３は、前述の通り、たとえば自動的にメカ系（用紙搬送系）や画像欠陥系の故障箇所を特定する故障診断を行なうに際しては、その診断アーキテクチャとして、障害発生前に正常時データを取得しておき、稼働状態の装置状態や環境条件などの観測データ（纏めて実働データともいう）を取得し、これらの情報を活用して、推論エンジンにて算出される故障確率なども参照の上、診断を行なう。本実施形態でいう故障診断とは、故障の有無の判断だけでなく、将来の故障の発生を予測する予測診断も含んでいてもよい。

推論エンジンや故障診断を行なう部分である故障確率推論部２６０や診断条件制御部４６０など故障診断に関わる機能部分は、画像形成装置１の本体に内蔵する構成に限らず、サーバ側、たとえば画像形成装置１とネットワーク接続された管理センタ４０１（データセンタとも称する）に設けてもよい。この場合、正常時データや実働データを、ネットワークを介して管理センタ４０１に送り、管理センタ４０１にて故障診断や確定処理や関連情報提示を行なう。

たとえば、画像形成装置１側で故障箇所や故障内容を特定せずに、故障確率推論部２６０にて行なった故障診断の検査内容とそこで使用した動作状態信号などのデータを管理センタ４０１に通知し、管理センタ４０１側で、故障候補の絞込みあるいは故障箇所や故障内容の特定などを行なうようにしてもよい。あるいは、推論エンジンのみを管理センタ４０１に置き、故障確率の算出を管理センタ４０１にて行なうようにしてもよい。

診断結果に関しては、たとえばカスタマーエンジニア（ＣＥ；Customers Engineer）が管理センタ４０１で確認する形態を採ってもよいし、管理センタ４０１で診断を行なう形態では故障確率推論部２６０による診断結果を画像形成装置１に送ることで、画像形成装置１側にて、カスタマーエンジニアやカスタマー（顧客／ユーザ）が確認する形態を採ってもよい。

ここで、本実施形態においては、故障確率の算出を行なう推論エンジンとしては、ベイジアン（Bayesian）ネットワークを利用する。ベイジアンネットワークを利用する故障診断は、ノード（変数）間の依存関係を確率的に捉え、グラフ構造（ベイジアンネットワークあるいは因果ネットワークと呼ばれる）を用いて、分布の推定を行なう最適化アプローチである。

たとえば、この診断システムに基づいて画像形成装置１の故障診断を行なう場合、画像形成装置１の品種やオプション構成などに応じて、故障事例やノウハウを元に交換パーツ単位を故障原因ノードとして因果ネットワークをそれぞれ作り、市場でのトラブル情報などを元にして条件付確率表の確率値を設定した診断モデルを構築し、障害が発生したときにセンサ部４やソフトウェア処理のログを記録しているログ記録部１６８などの観測可能な証拠情報を収集し、該当する装置構成に応じた診断モデルを選択して、証拠情報を入力して各故障原因ノードの故障発生確率を推定することで故障診断を行なう。

同様にソフトウェアの障害に対する故障診断も、予め開発者がコーディングしたエラーやワーニング、ＯＳ（Operating Systems ）が出力するメッセージなどを証拠情報とし、ソフトウェアコンポーネントの構成や呼び出し関係から因果ネットワークを作り確率値を設定した診断モデルを構築して、ソフトウェア故障診断をする。

＜故障診断装置：計算機構成＞
図３は、故障診断装置３の他の構成例を示すブロック図である。ここでは、パーソナルコンピュータなどの電子計算機を利用して、故障診断処理をソフトウェアを実行するマイクロプロセッサなどから構築されるより現実的なハードウェア構成を示している。

後述するベイジアンネットワーク手法を適用した故障診断処理を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なプログラムあるいはこのプログラムを格納したコンピュータ読取可能な記憶媒体が発明として抽出される。

もちろん、このようなコンピュータを用いた構成に限らず、図２に示した各機能部の機能をなす専用のハードウェアの組合せにより故障診断装置３や故障確率推論部２６０が構成される。ソフトウェアにより処理を実行させる仕組みとすることで、ハードウェアの変更を伴うことなく、処理手順などが容易に変更され得る。

電子計算機に一連のベイジアンネットワーク処理を利用した故障診断機能をソフトウェアにより実行させる場合には、電子計算機を利用した一般的な情報処理の場合と同様に、磁気ディスク（フレキシブルディスクＦＤを含む）、光ディスク（ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory ）、ＤＶＤ（Digital Versatile Disc）を含む）、光磁気ディスク（ＭＤ（Mini Disc ）を含む）、または半導体メモリなどよりなるパッケージメディア（可搬型の記憶媒体）や、有線あるいは無線などの通信網を介して、そのソフトウェアを構成するプログラムが電子計算機にインストールされる。ソフトウェアは、一括のプログラムファイルとして提供されることに限らず、コンピュータで構成されるシステムのハードウェア構成に応じて、個別のソフトウェアモジュールとして提供されてもよい。たとえば、既存の複写装置制御ソフトやプリンタ制御ソフト（プリンタドライバ）に組み込まれるアドインソフトとして提供されてもよい。

故障診断装置３を複写機能を持つ画像形成装置１に組み込む形態の場合、図３に示す電子計算機には、たとえば、複写アプリケーションやプリンタアプリケーション、ファクシミリ（ＦＡＸ）アプリケーション、あるいは他のアプリケーション用の処理プログラムなど、従来の画像形成装置（複合機）におけるものと同様のソフトウェアが組み込まれる。また、ネットワーク９を介して外部とのデータを送受信したりするための制御プログラムも組み込まれる。

たとえば、故障診断装置３を構成するコンピュータシステム９００は、コントローラー部９０１と、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）ドライブ、あるいはＣＤ−ＲＯＭ（Compact Disk ROM）ドライブ、半導体メモリコントローラなどの、所定の記憶媒体からデータを読み出したり記録したりするための記録・読取制御部９０２とを有する。

コントローラー部９０１は、ＣＰＵ（Central Processing Unit ）９１２、読出専用の記憶部であるＲＯＭ（Read Only Memory）９１３、随時書込みおよび読出しが可能であるとともに揮発性の記憶部の一例であるＲＡＭ（Random Access Memory）９１５、および不揮発性の記憶部の一例であるＲＡＭ（ＮＶＲＡＭと記述する）９１６を有している。ＮＶＲＡＭ９１６には、たとえば、使用時間、頻度、コピー／プリント枚数などで重み付けした各パーツの故障確率の情報を格納する。

“揮発性の記憶部”とは、故障診断装置３の電源がオフされた場合には、記憶内容を消滅してしまう形態の記憶部を意味する。一方、“不揮発性の記憶部”とは、故障診断装置３のメイン電源がオフされた場合でも、記憶内容を保持し続ける形態の記憶部を意味する。記憶内容を保持し続け得るものであればよく、半導体製のメモリ素子自体が不揮発性を有するものに限らず、バックアップ電源を備えることで、揮発性のメモリ素子を“不揮発性”を呈するように構成するものであってもよい。また、半導体製のメモリ素子により構成することに限らず、磁気ディスクや光ディスクなどの媒体を利用して構成してもよい。

また、コンピュータシステム９００は、カスタマーインタフェースをなす機能部として、キーボードやマウスなどを有する指示入力部９０３と、操作時のガイダンス画面や処理結果などの所定の情報をカスタマーに提示する表示出力部９０４と、各機能部との間のインタフェース機能をなすインタフェース部９０９（ＩＦ部）とを有する。

なお、故障診断装置３を複写機能やファクシミリ機能を持つ画像形成装置１（特に複合機と称する）に組み込んで一体化させる場合、処理対象の画像を読み取る画像読取部９０５（スキャナユニット）と、印刷出力用データを生成する画像処理部９６２および処理済みの画像を所定の出力媒体（たとえば印刷用紙）に出力するプリントエンジン９６４を具備した画像形成部９０６と、ファクシミリデータの処理を行なうＦＡＸ部９０７も設けられる。

インタフェース部９０９としては、処理データ（画像データを含む）や制御データの転送経路であるシステムバス９９１の他、たとえば、画像読取部９０５とのインタフェース機能をなすスキャナＩＦ部９９５、画像形成部９０６や他のプリンタとのインタフェース機能をなすプリンタＩＦ部９９６、およびインターネットなどのネットワーク９との間の通信データの受け渡しを仲介する通信ＩＦ部９９９を有している。

表示装置９０４は、たとえば、表示制御部９４２とＣＲＴ（Cathode Ray Tube；陰極線管）やＬＣＤ（Liquid Crystal Display；液晶）などでなるディスプレイ部９４４とを有する。たとえば、表示制御部９４２が、ディスプレイ部９４４上に、ガイダンス情報や画像読取部９０５が取り込んだ全体画像などを表示させる。また、故障判定結果や検査内容をカスタマーに通知する際の表示デバイスとしても利用される。表示面上にタッチパネル９３２を有するディスプレイ部９４４とすることで、指先やペンなどで所定の情報を入力する指示入力部９０３を構成してもよい。

なお、故障診断装置３の各機能部分の全ての処理をソフトウェアで行なうのではなく、これら機能部分の一部を専用のハードウェアにて行なう処理回路９０８を設けてもよい。ソフトウェアで行なう仕組みは、並列処理や連続処理に柔軟に対処し得るものの、その処理が複雑になるに連れ、処理時間が長くなるため、処理速度の低下が問題となる。これに対して、ハードウェア処理回路で行なうことで、高速化を図ったアクセラレータシステムが構築される。アクセラレータシステムは、処理が複雑であっても、処理速度の低下が防止され、高いスループットが得られるようになる。

画像形成装置１に適用した本実施形態の故障診断装置３の場合であれば、処理回路９０８としては、用紙通過時間、駆動電流、振動、作動音、あるいは光量などの観測データ情報、あるいは温度や湿度などの環境情報を取得するためのセンサ系統のデータ取得機能部９０８ａ（図２の動作状態情報取得部１４０に対応）や、ソフトウェア処理のログを記録するレジスタなどのソフトウェアデータ取得機能部９０８ｂ（図２のログ記録部１６８に対応）が該当する。なお、ソフトウェアデータ取得機能部９０８ｂは、ＲＡＭ９１５で実現されるように構成してもよい。なお、図示しないが、診断条件制御部４６０を構成する機能部の一部または全部をハードウェア構成にしてもよいのは言うまでもない。

＜故障診断処理：ソフトウェア欠陥診断モデル＞
図４は、故障確率推論部２６０においてソフトウェア障害の故障診断時に利用するベイジアンネットワークの構成例を示すベイジアンネットワークモデル図である。ここで、図４はベイジアンネットワークのより具体的な構成例であり、ソフトウェア欠陥系の故障箇所を特定する故障診断を行なう場合のベイジアンネットワーク診断モデルの構成例を示している。

本実施形態の故障診断方法としては、診断対象装置がそれぞれ異なる動作条件の元で動作している間の動作状態を示す動作状態信号をそれぞれ取得し、この取得したそれぞれの動作状態信号を、装置の故障を引き起こす原因をモデル化して解析することで、診断対象装置を構成する個々の構成部材について故障診断を行なう。「装置の故障を引き起こす原因をモデル化して解析する」とは、確率を利用して装置の故障を引き起こす原因をモデル化することで、故障の発生箇所や故障内容などの故障原因を解析することを意味する。モデル化の手法としては、確率を利用したものであればよく、一例としては、装置から取得される当該装置の状態を示す実測定値、あるいはこの実測定値から抽出される特徴量（纏めて変数ともいう）の間の依存関係を確率的に捉えてモデル化する手法がある。その具体例としては、ベイジアンネットワークモデルがある。

ベイジアンネットワークは、変数間の因果関係を表す有向非巡回グラフであり、親が与えられると、条件つき確率分布を変数に関連づけるものである。ベイジアンネットワークは、確率理論を使用して問題領域をモデル化する。各ノード（変数）は、相互に排他的な状態のセットを持つ。各ノードには、原因から結果が発生する確率（条件付き確率表）を予め設定しておく。そして、ベイジアンネットワークの大きな特徴は、直接観測できない状態（たとえば、故障の有無など）を直接観測（または入手）できる情報から確率推論し、直接観測できない状態の（故障か否かの）確率算出できることにある。

ソフトウェア障害に対する故障診断の場合も同様の考え方を適用すればよく、エラー・ワーニングなどを証拠情報とし、ソフトウェアコンポーネントの構成や呼び出し関係から因果ネットワークを作り確率値を設定した診断モデルを構築する。

たとえば、図中、Ｎｎ（Ｎ１，Ｎ２，…）は故障原因ノード、Ｅｅ（Ｅ１，Ｅ２，…）はエラー証拠情報ノード、Ｗｗ（Ｗ１，Ｗ２，…）はワーニング証拠情報ノードを示す。矢印は各ノードの因果関係を表し、矢印の元が原因、矢印の先が結果になる。つまり、各ノードは、“原因”→“結果”の関係になるように結線される。

たとえば、故障原因ノードＮ２とエラー証拠情報ノードＥ１の関係は“原因Ｎ２”が元で“エラー状態（モジュール２の欠陥など）”が表れるという関係になる。故障原因ノードＮ３，Ｎ６とワーニング証拠情報ノードＷ１の関係は“原因Ｎ３”や“原因Ｎ６”が元で“ワーニング状態（モジュール１にエラーが起こり得る状など）”が表れるという関係になる。故障原因ノードＮ３と故障原因ノードＮ１の関係は“原因Ｎ３”が元で“原因Ｎ１”（モジュール１の欠陥など）が発生するという関係が成り立つ。

各ノードには、予め条件付確率表中の中から該当する確率値（確率データ）を設定しておく。確率値は、たとえば、故障を起したときの各種の条件とその条件での故障が起こる確率を纏めた条件付確率表をノードごとに用意しておき、その条件付確率表中から対応する条件の確率値を読み出す形で設定する。確率値自体は、経験値によるものもあれば、実測によるデータも使ってもよい。故障の可能性が最も高い箇所（ノード：本例ではソフトウェアモジュール）を推測すると言う意味では、絶対値自体よりむしろ大小関係の方が重要となる。

各ノードの確率値の初期値は、たとえば過去のデータ（経験値や実測データ）を元に決定する。一例としては、製品出荷時に設計情報を元に診断モデルを構築しておく。基本的には、診断モデルがスタティックなため、その後、市場トラブル情報が推移した際には手動で確率更新をする。また、実稼動中に開発者が想定していないランタイムエラーや、外部ベンダが作成しインストールしたソフトウェアとの干渉によるエラーなどが生じる可能性があるため、ソフトウェア障害発生時には開発者が原因解析して対策を講じたソフトウェアの更新とともに診断モデルへの反映作業を行なう。たとえば、故障事例やハードウェア／ソフトウェアの設計情報を元に因果ネットワーク（診断モデル）を構築し、障害が発生したときに観測可能な証拠情報を収集して因果ネットワークに適用し、障害原因の推定を行なう。

つまり、電子機器の障害や故障などをベイジアンネットワークなどの診断モデルで診断を行なう場合、電子機器の品種やオプション構成などに応じて、故障事例やノウハウを元に、たとえば交換パーツ単位を故障原因ノードとして因果ネットワークをそれぞれ作り、市場でのトラブル情報などを元にして条件付確率の値を設定した診断モデルを構築し、障害が発生したときにセンサやレジスタなど観測可能な証拠情報を収集し、該当する機器構成に応じた診断モデルを選択して、証拠情報を入力して各故障原因ノードの故障発生確率を推定することで故障診断を行なう。

同様に、ソフトウェアの障害に対する故障診断も、予め開発者がコーディングしたエラーやワーニング、オペレーティングシステムが出力するメッセージなどを証拠情報とし、ソフトウェアコンポーネントの構成や呼び出し関係から因果ネットワークを作り確率値を設定した診断モデルを構築して、ソフトウェア故障診断をする。

このような状況下では、ソフトウェア環境の変化が起きたときには、その環境変化に対応した診断モデルの適用の有無で診断性能に影響を及ぼす。そのため、ソフトウェア環境の変化に対応して更新された診断モデルを市場の機器に展開する手順を踏むことになる。ただし、このような作業は、場合によっては多大な時間が掛るため、診断モデルが更新されるまでは古い診断モデルで故障診断することになり、診断性能の低下や誤診断が発生することが懸念される。

たとえば、ソフトウェアの更新や新規アプリケーションの追加などでソフトウェアの変更があった場合、変更箇所に対応したソフトウェア診断モデル部分を開発者が修正する必要があり、また、新たにソフトウェア不具合事例が発生した場合にも開発者が解析して診断モデルへ適用することが必要になる。開発者はソフトウェア更新部分をトレースして診断モデルに適用する作業や、市場で発生した新たな不具合情報を収集して原因を解析した後診断モデルに適用する作業などを行なって、更新された診断モデルを市場の機器に展開する手順を踏むため、ユーザが最新の診断モデルで診断を行なうまで時間が掛り、それまでは古い診断モデルを利用せざるを得ず、診断性能の低下や誤診断が生じてしまう。

その対策として、本実施形態の診断条件制御部４６０は、ソフトウェアの更新や新たな不具合に対して迅速かつ容易に診断モデルに反映するべく、ソフトウェア処理の処理履歴（処理過程の記録）を利用した以下のような仕組みを講じる。すなわち、ユーザが画像形成装置１を使用中にエラーやワーニングが発生したとき、そのエラーやワーニングのトリガの発生プロセスの処理履歴（たとえばバックトレースログやプロセスログ）を取得し、各ログを元に関数呼び出しグラフを作成し、因果ネットワークに変換する。発生したエラーやワーニングの情報は証拠情報としてバックトレースログおよびプロセスログと関連付け、因果ネットワークを診断モデルに組み込んでいく。処理履歴の取得は、ソフトウェア開発工程で使用されるいわゆるデバッキングの手法と同様の仕組みを使用すればよい。

＜故障診断システム：第１実施形態＞
図５および図５Ａは、複数台の画像形成装置１と通信回線を介して管理センタ４０１が接続されている故障診断システム４００の第１実施形態を示す図である。前述のように、故障確率推論部２６０あるいは診断条件制御部４６０など故障診断に関わる機能部分を画像形成装置１側に配するかサーバ側（たとえば管理センタ４０１）側に配するかは自由である。ここでは、画像形成装置１側に故障確率推論部２６０を配置して画像形成装置１側で故障診断を行なう場合での管理センタ４０１の構成例を示す。

故障診断システム４００は、診断モデルの生成・更新や適正化を行なう診断サーバ部４０１Ａを備える。図示する故障診断システム４００においては、センサ部４の観測データを、ＣＰＵ９１２、ＲＡＭ９１５あるいはＮＶＲＡＭ９１６などのメモリを利用してソフトウェア処理にて処理するように構成された複数の画像形成装置１（Ａ，Ｂ，…：Ｚは除く）が、インターネットなどの通信網４０６を介して管理センタ４０１と接続されている。通信網４０６には、画像形成装置１や管理センタ４０１の他、通信網４０６と接続されていない画像形成装置１Ｚについての故障発生情報を管理センタ４０１に通知するために利用されるパーソナルコンピュータPCが接続可能となっている。

図３に示したように、各画像形成装置１（Ａ，Ｂ，…，Ｚ）には、ソフトウェア処理のログを記録するレジスタなどのソフトウェアデータ取得機能部９０８ｂが設けられている。通信網４０６と接続されている画像形成装置１（Ａ，Ｂ，…：Ｚは除く）の場合、測定データを、通信ＩＦ９９９を介して外部に通知可能に構成されている。管理センタ４０１には、ホストコンピュータが設けられており、通信網４０６を介して、画像形成装置１（Ａ，Ｂ，…：Ｚは除く）との間で、通信処理が可能になっている。

通信網４０６に接続された複数の画像形成装置１（Ａ，Ｂ，…：Ｚは除く）は、たとえばサービスエンジニアSE（Service Engineer）が故障発生情報を、操作パネルなどを通して入力することにより、管理センタ４０１に故障情報を送信するように構成されている。故障発生情報の操作パネルからの入力は、たとえば階層的にメニューが表示され、選択するよう構成されている。また、通信網４０６に接続されていない画像形成装置１Ｚに関しては、故障発生情報を画像形成装置１Ｚにより印字出力し、サービス拠点でＯＣＲ（Optical Character Reader）入力する構成をとってもよい。

因みに、管理センタ４０１側で診断モデルを用意する場合、管理センタ４０１は、複数の画像形成装置１の情報に基づき診断モデルを構築する。この仕組みを採るため、管理センタ４０１は、市場品質情報データベース４０２ａに蓄積された各装置の故障内容に関する故障情報（市場品質情報とも称する）を用いて診断モデルを生成し、また、適宜更新する。そして、因果ネットワークを構成する各ノードに条件付確率表を備えた因果ネットワークで構成される診断モデルに基づいて診断対象装置に生じる故障を診断するようにする。市場品質情報データベース４０２ａは、各装置の故障内容に関する故障情報を格納する故障情報格納部の一例である。

診断サーバ部４０１Ａは、診断モデルの生成・更新や適正化を管理するため、データベース部４０２と、診断モデルを生成・更新する診断モデル生成・更新部４１０と、図２に示した故障診断装置３における診断条件制御部４６０の部分を備える。また、管理センタ４０１は、市場で発生した品質情報（トラブルの故障内容、以下市場品質情報と称する）を故障箇所（故障した部位やソフトウェアモジュール）ごとに収集する市場品質情報収集部４２２と、各種情報の送受信を行なう通信部４２４を備える。

本例では、管理センタ４０１にて故障診断を行なう形態を採らずに、各画像形成装置１が故障診断装置３の故障確率推論部２６０を搭載し、画像形成装置１側にて故障診断を行なう形態で示すが、管理センタ４０１にて故障診断を行なう形態とする場合には、ホストコンピュータには、画像形成装置１側の故障診断装置３を構成するデータ取得機能部９０８ａを除く、故障診断に関わる特徴量取得機能部分や、故障判定機能部分および推論エンジン機能部分や、診断モデルを適正化する機能部分（診断条件制御部４６０に対応）などのデータ処理機能部分をソフトウェア処理にて実現するためのアプリケーションプログラムがインストールされる。

この場合、基本的には、たとえば、データ受取機能部としての特徴量取得機能部分は診断情報収集部１６０である。また、データ処理機能部分としては、たとえば、故障判定部２６２、推論エンジン２６４（当然に診断条件制御部４６０も）などである。このような構成により、故障診断システム４００は、インターネットなどの通信回線を利用して、装置外部の管理センタ４０１に、故障判定部２６２や推論エンジン２６４などを備える故障診断部を設けたシステムとなり、管理センタ４０１のホストコンピュータにて、画像形成装置１について故障診断を行なうように構成される。管理センタ４０１においては、測定データやソフトウェアログや、この測定データやソフトウェアログから抽出される特徴量に基づいて、ホストコンピュータが自動的に、ベイジアンネットワークを利用して部品やソフトウェアモジュールの故障確率を決定し故障箇所を特定する。

機能的に示すと、診断サーバ部４０１Ａで故障診断を行なう構成を採る場合には、点線で示すように、診断対象装置から当該装置の診断に必要な情報（診断情報）を取得する診断情報取得部４２０と、診断情報取得部４２０が取得した診断情報を元に故障診断を行なう故障確率推論部４３０（図２の故障確率推論部２６０に対応）を備えることになる。故障確率推論部４３０は、故障診断の結果、故障確率が予め定められた閾値以上の上位の故障原因候補を抽出して、画像形成装置１側に通知する。

以下、本実施形態の管理センタ４０１が備える診断モデル適正化処理機能に関わる部分について詳しく説明する。本実施形態の「診断モデル適正化処理機能」は、ソフトウェア障害の故障診断条件として利用される診断モデルが、ソフトウェア更新や新たな不具合が診断モデルへ迅速に反映されたものとなるように制御する診断条件制御部４６０が備える機能である。

因みに、管理センタ４０１側で診断モデルを用意する場合、管理センタ４０１は、複数の画像形成装置１の情報に基づき診断モデルを構築する。この仕組みを採るため、管理センタ４０１は、市場品質情報データベース４０２ａに蓄積された各装置の故障内容に関する故障情報（市場品質情報とも称する）を用いて診断モデルを生成し、また、適宜更新する。そして、因果ネットワークを構成する各ノードに条件付確率表を備えた因果ネットワークで構成される診断モデルに基づいて診断対象装置に生じる故障を診断するようにする。市場品質情報データベース４０２ａは、各装置の故障内容に関する故障情報を格納する故障情報格納部の一例である。

「故障情報」としては、たとえば、市場でのトラブル対応事例ごとに、故障内容、その故障に対する処置を行なった作業者、機械Ｎｏ．、処置対象部品、処置内容（処置コード）、作業に要した時間（作業時間）、その他作業内容情報が記録されている。

市場品質情報データベース４０２ａの故障情報は、リスト形式で構成され、たとえば、日時、機械番号、サービスエリアコード、地域エリアコード、お客様コード、故障箇所情報コード、故障現象情報コード、処置情報コードで構成されている。なお、故障現象コードに対応する故障現象は、故障診断モデルごとに設定される。市場品質情報データベース４０２ａには、市場品質情報収集部４２２が各画像形成装置１から故障情報を収集する形態に限らず、たとえば、市場品質情報収集部４２２がサービスエンジニアの訪問履歴情報から上記内容を抽出して格納してもよい。

なお、図示しないが、第１構成例の市場品質情報データベース４０２ａと市場品質情報収集部４２２とを管理センタ４０１（の診断サーバ部４０１Ａ）から取り外して、専用のサーバ装置（市場品質管理サーバ）を設けて通信網４０６に接続し、市場品質管理サーバ内に市場品質情報データベース４０２ａと市場品質情報収集部４２２を設ける構成を採ってもよい。

診断モデル生成・更新部４１０は、画像形成装置１側の診断情報収集部１６０やログ記録部１６８との協業により市場品質情報収集部４２２により収集し市場品質情報データベース４０２ａに蓄積した市場品質情報に基づき、故障現象ごとや所定期間ごとに、故障部位ごとの、モデル化した故障原因の発生頻度を算出する故障発生頻度算出部４１２と、一定期間ごとに市場品質情報データベース４０２ａから故障発生状況を取得して診断モデルの条件付確率表を更新する確率表更新部４１９を診断モデル更新部として備える。因みに、診断モデル（詳しくは条件付確率表）の更新は、条件付確率表の確率値の更新やノードの追加（この際にはその追加ノードに確率値が設定される）で実現される。故障発生頻度算出部４１２は、算出した故障原因の発生頻度を元に構成部品の故障原因を診断するための診断条件としての診断モデルを診断モデルデータベース４０２ｂに登録する。

また、第１実施形態の診断サーバ部４０１Ａは、ソフトウェアの更新や新たな不具合に対して迅速かつ容易に診断モデルに反映するための診断条件制御部４６０は、次のような機能部を備える。

診断サーバ部４０１Ａの診断条件制御部４６０は、ソフトウェア障害の故障診断を行なうための本実施形態に特徴的な構成要素として、エラーやワーニングを検出するエラー／ワーニング検出部４６２と、エラー／ワーニング検出部４６２により検出されたエラーやワーニングをトリガにしてソフトウェア処理の履歴（ログ）を取得するログ取得部４６４を有する。

また、診断条件制御部４６０は、バックトレースログ取得部４６４Ａが取得したバックトレースログに基づき呼出し関数グラフを生成する呼出し関数グラフ生成部４７２と、呼出し関数グラフ生成部４７２が生成した呼出し関数グラフに基づいてソフトウェア処理を起因とする障害に関するサブ因果ネットワークを生成するサブ因果ネットワーク生成部４７４を有する。ソフトウェア処理を起因とする障害に関するサブ因果ネットワークとは、ソフトウェア処理を起因とする障害の１つまたは複数の原因となるソフトウェアモジュールと各ソフトウェアモジュールが原因となる確率を関連付けたものである。

サブ因果ネットワーク生成部４７４は、ソフトウェア処理を起因とする障害を障害発生の契機となった可能性がある１つまたは複数のソフトウェアモジュール（ライブラリモジュール）での誤動作に関連付け、障害の条件付き確率を障害（誤動作）のそれぞれの確率に関係付けるサブ因果ネットワークを生成する。たとえば、サブ因果ネットワーク生成部４７４は、呼出し関数グラフ生成部４７２が生成した呼出し関数グラフに基づき、ソフトウェアモジュール単位で纏めてそのモジュールをノードに変換し、呼出し関数をノードのステートに変換することでサブ因果ネットワークを生成するようにする。

さらに、診断条件制御部４６０は、サブ因果ネットワーク生成部４７４が生成したサブ因果ネットワークを既存の診断モデルに組み込むことで、診断モデルを診断対象装置に適合したものとなるようにする（好ましくは診断対象装置に合わせて最適化する）診断モデル適正化部４７６を有する。

ここで、ログ取得部４６４は、サブ因果ネットワークの生成に資するソフトウェア処理時の処理履歴を取得するものであればよく、ソフトウェア処理時の処理履歴としては、たとえば、バックトレースログやプロセスログ、あるいは、メモリリークのログやシステムログなどを適用し得る。また、サブ因果ネットワーク生成部４７４は、各ログを組み合わせてサブ因果ネットワークを生成してもよい。第１実施形態は、ソフトウェア処理時の処理履歴としてバックトレースログを適用する事例であり、第１実施形態のログ取得部４６４は、バックトレースログを取得するバックトレースログ取得部４６４Ａを具備する点に特徴を有する。

一方、図５Ａに示す第２構成例では、第１構成例の診断条件制御部４６０を診断サーバ部４０１Ａから取り外して、故障確率推論部２６０だけでなく診断条件制御部４６０も画像形成装置１側に搭載した構成例を示している。

このような第１実施形態の仕組みを採ることで、製品出荷後のソフトウェア更新や新たな不具合に対して、診断モデルへの反映を迅速にかつ容易に行なうようにし、ソフトウェア診断性能を向上させる。

＜動作例：第１実施形態の概要＞
図６は、第１実施形態の故障診断システム４００における診断条件適正化処理（（故障診断モデル適正化処理）を説明する図である。ここで、図６は第１実施形態の故障診断モデル適正化処理の手順を示すフローチャートである。ここでは、診断条件制御部４６０が画像形成装置１側に搭載されている第２構成例の場合で説明する。

たとえば、第１実施形態のシステム構成においては、ログ取得部４６４はバックトレースログ取得部４６４Ａを具備しており、エラー／ワーニング検出部４６２によりエラーやワーニングが検出されるとバックトレースログ取得部４６４Ａでバックトレースログを取得し、このバックトレースログに基づき呼出し関数グラフ生成部４７２で呼出し関数グラフを生成する。この呼出し関数グラフの生成時には、バックトレースログから関数／モジュール記述リストを抽出し、この関数／モジュール記述リストを使用して呼出し関数グラフを生成する（その詳細は後述する）。

たとえば、ログ記録部１６８は、ソフトウェアによって動作する画像形成装置１のソフトウェアの処理過程を記録しておく（Ｓ１００）。本例では、特に障害発生時にバックトレースログＢＬを取得できるようにしておく。そして、エラー／ワーニング検出部４６２は、エラーやワーニングがソフトウェアあるいはＯＳから出力されたことを検出すると（Ｓ１０２−ＹＥＳ）、ログ取得部４６４に、バックトレースログの取得を指示する（Ｓ１０４）。ただし、ワーニングの場合には予めソフトウェアにワーニング出力と同時にプログラムを一時停止してバックトレース取得プログラムを動作させ、終了したらソフトウェアを再開する記述を記載しておく。

この指示を受けたログ取得部４６４は、バックトレースログ取得部４６４ＡによりバックトレースログＢＬを取得し、取得したバックトレースログＢＬを呼出し関数グラフ生成部４７２に渡す（Ｓ１０６）。

呼出し関数グラフ生成部４７２は、ログ取得部４６４から受け取ったバックトレースログＢＬに基づいて、呼出し関数グラフを生成する（Ｓ１１０）。呼出し関数グラフの生成時には、先ず、バックトレースログＢＬの記述から、呼出し関数と、この呼出し関数が含まれるライブラリモジュールを抽出し、ログ順（呼出し順）に羅列することで関数／モジュール記述リストを生成し、エラーやワーニングが発生したときの呼出しパスを取得する（Ｓ１１２）。そして、関数／モジュールの単位を纏めてグラフ化することで呼出し関数グラフを作成し、作成した呼出し関数グラフをサブ因果ネットワーク生成部４７４に渡す（Ｓ１１４）。バックトレースログＢＬに基づく関数／モジュール記述リストの生成手法と、関数／モジュール記述リストに基づく呼出し関数グラフの生成手法の具体的事例については後述する。

サブ因果ネットワーク生成部４７４は、呼出し関数グラフ生成部４７２で生成された呼出し関数グラフに基づいて、サブ因果ネットワークのノードやステート並びにリンクへ変換することでサブ因果ネットワークを生成する（Ｓ１２０）。なお、呼出し関数グラフからノード／ステートへの変換は、その詳細は後述するが、たとえば、サブ因果ネットワーク生成部４７４は、呼出し関数グラフをライブラリモジュール単位で纏め（Ｓ１２２）、ライブラリモジュールをノード、関数をそのノードのステートとして割り付ける（Ｓ１２４）。あるいは、変換テーブルを保持し、テーブルの参照によって変換してもよい。そして、サブ因果ネットワーク生成部４７４は、各ノードを呼出し関数グラフの矢印の向きに基づきリンクを生成することで、サブ因果ネットワークを完成させる（Ｓ１２６）。

次に、診断モデル適正化部４７６は、サブ因果ネットワーク生成部４７４が生成したサブ因果ネットワークを既存の診断モデルに組み込むことで、診断モデルを診断対象装置に適合したものとなるようにする（Ｓ１６０）。このとき、診断モデル適正化部４７６は、既存の診断モデル（既存モデルと称する）に対して、サブ因果ネットワークのノード名とリンクを検索し（Ｓ１６２）、既存モデルに存在するノードであればステートの追加や確率値の更新を行ない（Ｓ１６４−ＹＥＳ，Ｓ１６６）、既存モデルに存在しない新規ノードであればノード，リンク，条件付き確率表に確率テーブルを追加する（Ｓ１６４−ＮＯ，Ｓ１６８）。

診断モデル適正化部４７６は、サブ因果ネットワーク生成部４７４で生成されたサブ因果ネットワークを既存の診断モデルに組み込むことで適正化した適性診断モデルを所定の記憶媒体（たとえば判定指標格納部２３０）に記憶する（Ｓ１８０）。なお、診断モデル適正化部４７６は、適性診断モデルを既存の診断モデルと置き換えてもよいし、適正化した適性診断モデルを記憶しつつ、既存の診断モデルをそのまま残して置くようにしてもよい。

診断モデル適正化部４７６によって適正化された適性診断モデルは、出荷後のソフトウェア更新や新たな不具合への対応など、その時点での最新のソフトウェア環境が反映されたもので、以降の故障診断時に利用され得る状態となる。

＜バックトレースログ＞
図７は、第１実施形態において適用されるエラー証拠情報ノードＥｅ（ｅはノード番号）に関するバックトレースログの一例を示す図である。バックトレースログＢＬは、ソフトウェア（プログラム）が現在いる箇所にどのようにして到達したかを示す要約情報であり、エラーで停止した際やプログラムが一時停止した際にモジュール／関数の呼出しスタックを遡って出力したログであり、＃で示す行番号ごとに、順に呼出し元まで辿る。ログの最初の行の記述はバックトレースログＢＬを一意に特定する記述である。各行は、基本的には、アドレス（＃＊とinの間の記述）、呼出し関数（inとfromの間の記述）、呼出し関数が含まれるライブラリモジュール（from以降の記述）の順に表示されている。ライブラリモジュールの記述のある行が、呼出し関数グラフの生成に関わる記述である。たとえば、＃２は“／ｕｓｒ／ｌｉｂ／ｌｉｂｇｎｏｍｅｕｉ−２．ｓｏ．０”という共有ライブラリモジュールに含まれる“ｇｎｏｍｅ＿ｇｔｋ＿ｍｏｄｕｌｅ＿ｉｎｆｏ＿ｇｅｔ（）”という呼出し関数からの呼び出しがあったことを示す。

なお、ライブラリモジュールの記述の無い＃０行は、ＯＳに関わる呼出し関数の記述である。アドレス、呼出し関数、ライブラリモジュールの何れも記述されていない＃３行は、あるイベントが発生したことを示している。

このようにして、ログ取得部４６４は、エラーで停止した場合の呼出しパスを取得することになる。また、ワーニングの場合はソフトウェア（プログラム）にワーニングメッセージ出力時に一時停止してバックトレースを動作させ、終了時にソフトウェアを再開するので、同様にログ取得部４６４はワーニング発生時の呼出パスを取得することになる。

＜呼出し関数グラフの生成方法＞
図８および図９は、呼出し関数グラフ生成部４７２による呼出し関数グラフの生成方法の具体例を説明する図である。ここで、図８は、エラー証拠情報ノードＥｅに関するバックトレースログＢＬから抽出した関数／モジュール記述リストの一例を示す。図９は、エラー証拠情報ノードＥｅに関する呼出し関数グラフの一例を示す図である。

呼出し関数グラフの生成時には、先ず、図７に示したバックトレースログＢＬにおける“in”から“from”の間の記述を呼出し関数として抽出し、“from”に続く記述をその呼出し関数が含まれるライブラリモジュールとして抽出し、行番号（＃番号）の順に羅列することで、図８に示すような関数／モジュール記述リストを作成する（Ｓ１１２）。

この後、呼出し関数グラフ生成部４７２は、関数の単位を“Ｆｍ／Ｍｍ”としてグラフ化することで、図９に示すような呼出し関数グラフを作成する（Ｓ１１４）。ここで、Ｆｍは呼出し関数、Ｍｍはその呼出し関数が含まれるライブラリモジュールであり、“Ｆｍ／Ｍｍ”のｍは、図７、図８の行番号（＃番号））と対応する。たとえば、図９において、Ｆ２は、＃２行目における呼出し関数“ｇｎｏｍｅ＿ｇｔｋ＿ｍｏｄｕｌｅ＿ｉｎｆｏ＿ｇｅｔ（）”であり、Ｍ２は、＃２行目における共有ライブラリモジュール“／ｕｓｒ／ｌｉｂ／ｌｉｂｇｎｏｍｅｕｉ−２．ｓｏ．０”である。因みに、図７、図８に示す例では、ライブラリモジュールの記述のある＃１，＃２，＃４〜＃１２の各行が呼出し関数グラフの生成に関わる記述であり、イベントの発生を示す＃３行目が除かれている。

＜サブ因果ネットワークの生成方法：第１実施形態＞
図１０は、第１実施形態のサブ因果ネットワーク生成部４７４によるサブ因果ネットワークの生成方法の具体例を説明する図である。

ライブラリモジュールは複数の呼出し関数を含む場合が多いので、サブ因果ネットワーク生成部４７４は先ず、呼出し関数グラフをライブラリモジュール単位で纏める（Ｓ１２２）。また、ライブラリモジュールをノード、呼出し関数をそのノードのステートとして割り付ける（Ｓ１２４）。

たとえば、図７、図８の例では、ライブラリモジュール“/usr/lib/libgdk-x11-2.0.so.0”は、＃５行目の呼出し関数“gdk_region_rectangle()”を含むため、下記のように、＃５行目の呼出し関数にステート番号を設定する。
ノードＮ４：/usr/lib/libgdk-x11-2.0.so.0
ステート１：gdk_region_rectangle() ：（＃５）

また、ライブラリモジュール“/usr/lib/libgtk-x11-2.0.so.0”は、＃６，＃７および＃８，＃９，＃１０および＃１１，＃１２行目の各呼出し関数を含むので、下記のように、＃６，＃７および＃８，＃９，＃１０および＃１１，＃１２行目の呼出し関数にそれぞれ別のステート番号を設定する。
ノードＮ５：/usr/lib/libgtk-x11-2.0.so.0
ステート１：gtk_widget_region_intersect () ：（＃６）
ステート２：gtk_container_propagate_expose ()：（＃７，＃８）
ステート３：gtk_box_pack_start_defaults () ：（＃９）
ステート４：gtk_container_forall() ：（＃１０，＃１１）
ステート５：gtk_marshal_BOOLEAN__VOID () ：（＃１２）

ここで、ノードＮｎにおけるｎはノード番号を示し、サブ因果ネットワーク生成時には暫定的に１からの通し番号を割り当てる。

サブ因果ネットワーク生成部４７４は、ライブラリモジュールに割り付けたノードをサブ因果ネットワークのノードに設定し、呼出し関数グラフの矢印の向きに基づいてリンクを生成することで、図１０に示すようなサブ因果ネットワークを生成する。ここで、複数の呼出し関数を含むライブラリモジュールに割り付けられたノードの配置順は、図７、図８における行番号（＃番号）の小さい方からノード番号に割り当てていくようにする。

たとえば、エラー証拠情報ノードＥｅに関する図９（元は図７、図８）に示す例では、呼出し関数グラフの生成に関わる（つまりライブラリモジュールの記述のある）＃１，＃２，＃４〜＃１２の各行において、＃６〜＃１２の各行の呼出し関数が同一のライブラリモジュールに含まれるので、サブ因果ネットワーク生成部４７４は、図１０に示すように、＃１行目に関するノードＮ１、＃２行目に関するノードＮ２、＃４行目に関するノードＮ３、＃５行目に関するノードＮ４、＃６〜＃１２行目に関するノードＮ５の順で各ノードＮｎを順に配置する。そして、サブ因果ネットワーク生成部４７４は、ノードＮ５から順番にノードＮ１の方向に向かって（呼出し関数グラフの矢印の向きとは逆向きで）リンクを生成するとともに、ノードＮ５からエラー証拠情報ノードＥｅに向かってリンクを生成することで、サブ因果ネットワークを完成させる（Ｓ１２６）。各ノードＮｎにはノード名としてライブラリモジュールＭｍが与えられ、ステートとして呼出し関数Ｆｍが付加されている。

＜診断モデル適正化処理：第１実施形態＞
図１１は、第１実施形態の診断モデル適正化部４７６における診断条件適正化処理（診断モデル適正化処理：事実上の診断モデル更新処理）の詳細を説明する図である。診断モデル適正化部４７６は、サブ因果ネットワーク生成部４７４が生成したサブ因果ネットワークを既存の診断モデルに組み込むのであるが、第１実施形態の場合には、図４に示したような更新前（既存）の診断モデルに対して、サブ因果ネットワークのノード名とリンクを検索し、更新前の診断モデルに存在するノードなら、ノード番号は変更せずステートの追加・確率の更新を行ない、更新前の診断モデルに存在しない新規ノードなら更新前の診断モデル内のノード番号と重複せずかつ番号の小さいものに再割り当てを行ない、ノード・リンク・確率テーブルを追加する。

たとえば、図４に示した更新前の診断モデルに関して、新たなエラーが発生したとき（エラー証拠情報ノードＥ４）、サブ因果ネットワーク生成部４７４により生成されたサブ因果ネットワークが、図１１（１）に示すように、サブ因果ネットワーク生成部４７４によりノードはＮ１，Ｎ２，Ｎ３の３つが存在し、ノードＮ３→ノードＮ２→ノードＮ１に向かってリンクが生成され、また、ノードＮ３からエラー証拠情報ノードＥ４に向かってリンクが生成されているものとする。またＮ１，Ｎ２は更新前の診断モデルに存在する既存ノードで、Ｎ３は存在しない新規ノードとする。

この場合、サブ因果ネットワーク生成部４７４により生成されたサブ因果ネットワークのノードＮ２とノードＮ１は、更新前の診断モデルに存在する既存ノードであるので、図１１（２）に示すように、診断モデル適正化部４７６は、これらノードＮ２とノードＮ１に関しては、その既存ノードをそのまま使うとともに、ステートの追加や確率値の更新を行なう。一方、ノードＮ３は更新前の診断モデルに存在しない新規ノードであるので、診断モデル適正化部４７６は、図１１（２）に示すように、ノードＮ３を更新前診断モデルのノードと重複せずかつ番号の小さいものとしてＮ１１というノード番号を再割り当てして追加するとともにそのノードに確率値を設定（追加）する。また、追加したノードＮ１１からノードＮ２およびエラー証拠情報ノードＥ４に向かってリンクを作成する。図１１（２）において、ハッチングしたノードＮ１，Ｎ２，Ｎ１１，Ｅ４と、それらのリンクが、サブ因果ネットワーク生成部４７４により作成されたサブ因果ネットワークを組み込んだ部分となる。

このような第１実施形態の仕組みによれば、エラーやワーニングをトリガとして取得したバックトレースログＢＬに基づき生成されたサブ因果ネットワークが即座に既存（更新前）の診断モデルに組み込まれることになる。

特許文献１〜３に記載の仕組みでは、ソフトウェア診断モデルの更新に関する記載はなく、ソフトウェア更新や新たな不具合に対して診断モデルへの反映が迅速に行なわれないので、ソフトウェア診断精度の低下や誤診断を招く虞れがある。

これに対して、第１実施形態の仕組みでは、エラーやワーニングをトリガとしてソフトウェア処理の処理履歴（処理過程の記録）の一例であるバックトレースログＢＬを取得し、このバックトレースログＢＬに基づいてサブ因果ネットワークを生成し、このサブ因果ネットワークを更新前の診断モデルに組み込むようにした。このため、たとえば、実稼動中に開発者が想定していないランタイムエラーや、外部ベンダが作成しインストールしたソフトウェアとの干渉によるエラーなどが生じた場合でも、それらソフトウェア処理における故障状況が、迅速かつ容易に診断モデルに反映されることになり、ソフトウェア診断の診断性能が向上する。製品出荷後のソフトウェア更新や新たな不具合に対して、診断モデルへの反映が迅速にかつ容易に行なわれることで、ソフトウェア診断性能が向上するようになる。

なお、相互リンクされた複数のモジュールから構成されたシステムの故障診断を行なうに当たり、障害発生を契機としてサブ因果ネットワークを生成し、このサブ因果ネットワークを既存の診断モデルの因果ネットワークに組み込むという点では、特許文献１に記載の仕組みと似通っていると指摘されるかも知れない。しかしながら、本実施形態は複数のソフトウェアモジュールから構成されたソフトウェア処理システムの故障診断を行なうものであり、ソフトウェア処理履歴を利用してサブ因果ネットワークを生成するという構成上の相違があり、この構成上の相違から、特許文献１に記載の仕組みでは得られない次のような特有の作用が得られる。

すなわち、特許文献１では障害モデルとして予め想定される障害の因果関係を複数登録しておき、発生した障害に応じて該当するモデルを照会して再帰的に因果ネットワークに組み込むため、事前に知識ベースの障害モデルを構築しておく必要があることと、障害モデルが非常に大きくなってしまうのを抑制するために障害モデルのサイズの制限手段が必要になることから処理の負荷が大きくなる。これに対して、本実施形態の仕組みでは、知識ベースの障害モデルデータベースを予め構築しておく必要がなく、さらに発生した障害のみをリアルタイムで障害モデルに組み込むために、診断モデルのサイズが大きくなることを抑制するとともに、診断モデルのサイズの制限手段が不要で処理負荷が軽い、という特有の作用が得られる。

＜故障診断システム：第２実施形態＞
図１２は、複数台の画像形成装置１と通信回線を介して管理センタ４０１が接続されている故障診断システム４００の第２実施形態（第２構成例）を示す図である。ここでは、図５Ａに示した第２構成例に対する変形例で示すが、図５に示した第１構成例に対しても同様の変形を加え得る。

第２実施形態は、ソフトウェア処理時の処理履歴としてプロセスログＰＬを適用する事例であり、第２実施形態のログ取得部４６４は、バックトレースログ取得部４６４Ａに加えて、プロセスログＰＬを取得するプロセスログ取得部４６４Ｂを具備する点に特徴を有する。これに対応して、第２実施形態のサブ因果ネットワーク生成部４７４は、プロセスログ取得部４６４Ｂが取得したプロセスログＰＬ中のプロセスリストを原因とし障害の発生（エラーやワーニング）が結果とすることでサブ因果ネットワークを生成する。プロセスログＰＬから原因と結果がリンクされたサブ因果ネットワークが生成されるので、診断モデル適正化部４７６は特段の対処をしなくとも、プロセスログ取得部４６４ＢがプロセスログＰＬに基づき生成したサブ因果ネットワークをそのまま既存の診断モデルに組み込めばよい。その他の点は、第１実施形態と同様である。

因みに、バックトレースログ取得部４６４Ａを取り外して、プロセスログ取得部４６４Ｂを備える構成にしてもよい。この場合、第２実施形態の診断条件制御部４６０は、呼出し関数グラフ生成部４７２を備えない。

＜動作例：第２実施形態の概要＞
図１３は、第２実施形態の故障診断システム４００における診断条件適正化処理（故障診断モデル適正化処理）を説明する図である。ここで、図１３は第２実施形態の故障診断モデル適正化処理の手順を示すフローチャートである。ステップ番号を２００番台で示すとともに、第１実施形態と同様の処理ステップには同一の１０番台および１番台の番号を付して示す。ここでは、診断条件制御部４６０が画像形成装置１側に搭載されている第２構成例の場合で説明する。

たとえば、第２実施形態のシステム構成においては、ログ取得部４６４はプロセスログ取得部４６４Ｂを具備しており、エラー／ワーニング検出部４６２によりエラーやワーニングが検出されるとプロセスログ取得部４６４ＢでプロセスログＰＬを取得し、このプロセスログＰＬに基づき、サブ因果ネットワーク生成部４７４は、プロセスログＰＬ中のプロセスリストを原因としエラーやワーニングが結果となるサブ因果ネットワークを生成する（その詳細は後述する）。

たとえば、ログ記録部１６８は、ソフトウェアによって動作する画像形成装置１のソフトウェアの処理過程を記録しておく（Ｓ２００）。本例では、特に障害発生時にプロセスログＰＬを取得できるようにしておく。そして、エラー／ワーニング検出部４６２は、エラーやワーニングがソフトウェアあるいはＯＳから出力されたことを検出すると（Ｓ２０２−ＹＥＳ）、ログ取得部４６４に、バックトレースログの取得を指示をする（Ｓ２０５）。この指示を受けたログ取得部４６４は、プロセスログ取得部４６４ＢによりプロセスログＰＬを取得し、取得したプロセスログＰＬをサブ因果ネットワーク生成部４７４に渡す（Ｓ２０７）。つまり、エラー／ワーニング検出部４６２でエラーやワーニングを検出したとき、ログ取得部４６４はプロセスログ取得部４６４Ｂによりその時点でのプロセスログを取得する。すなわち、エラーやワーニング発生時点に起動していたプロセスを抽出する。

サブ因果ネットワーク生成部４７４は、プロセスログ取得部４６４Ｂから渡されたプロセスログＰＬに基づいて、サブ因果ネットワークのノードやステート並びにリンクへ変換することでサブ因果ネットワークを生成する（Ｓ２２０）。なお、サブ因果ネットワーク生成部４７４におけるプロセスログＰＬからサブ因果ネットワークへの変換は、たとえば、プロセスログＰＬ中のプロセスリストを原因ノードに割り当て、エラーやワーニングを結果ノードに割り当てることで、サブ因果ネットワークを生成する（Ｓ２２３）。これは、初期段階では、エラーやワーニングの発生時点に起動していたプロセスが、発生したエラーやワーニングの原因となると考えてよいからである。

診断モデル適正化部４７６は、サブ因果ネットワーク生成部４７４で生成されたサブ因果ネットワークを既存の診断モデルに組み込むことで診断モデルを適正化し（Ｓ２６０）、この適正化した適性診断モデルを所定の記憶媒体（たとえば判定指標格納部２３０）に記憶する（Ｓ２８０）。

診断モデル適正化部４７６によって適正化された適性診断モデルは、出荷後のソフトウェア更新や新たな不具合への対応など、その時点での最新のソフトウェア環境が反映されたもので、以降の故障診断時に利用され得る状態となる。

＜プロセスログ＞
図１４は、第２実施形態において適用されるエラー証拠情報ノードＥｅやワーニング証拠情報ノードＷｗ（ｗはノード番号）に関するプロセスログＰＬの一例を示す図である。プロセスログＰＬは、ソフトウェア処理における処理プロセスの履歴を示したものである。一例として、プロセスログＰＬには、プロセス名・プロセスＩＤ・親プロセスＩＤ・起動日時・プロセス時間などが含まれる。

たとえば、図１４において、“ＵＩＤ”はプロセスを起動したユーザを一意に特定する識別子（ＩＤ）、“ＰＩＤ”はプロセスを一意に特定する識別子（ＩＤ）、“ＰＰＩＤ”は起動したプロセスの親プロセスを一意に特定する識別子（ＩＤ）、“Ｃ”はＣＰＵの使用率（％）、“ＳＴＩＭＥ”はプロセスの起動日時、“ＴＴＹ”はプロセスを起動したものがターミナル・コンソール・自動の何れかの切分け（？は自動であったことを示す）、“ＴＩＭＥ”はプロセスの累積ＣＰＵ時間、“ＣＭＤ”はコマンド、をそれぞれ示す。

＜診断モデル適正化処理：第２実施形態＞
図１５は、第２実施形態の診断モデル適正化部４７６における診断モデル適正化処理（事実上の診断モデル更新処理）の詳細を説明する図である。診断モデル適正化部４７６は、サブ因果ネットワーク生成部４７４が生成したサブ因果ネットワークを既存の診断モデルに組み込むのであるが、第２実施形態の場合には、更新前（既存）の診断モデルに対して、初期段階では、プロセスが、発生したエラーやワーニングの原因となると考えて、更新前（既存）の診断モデルにおいて、プロセスＰｐをエラー証拠情報ノードＥｅやワーニング証拠情報ノードＷｗに直接リンクさせる。その後、更新を重ねるごとに発生回数から確率値を自動調整し、場合によってはリンクを追加することで、より現実の障害発生状況に応じた診断モデルへと更新していく。

たとえば、図１５は、図１１に対しての適用事例を示している。エラー証拠情報ノードＥ４に関して、サブ因果ネットワーク生成部４７４により生成されたサブ因果ネットワークは、図１５に示すように、プロセスＰ１，Ｐ２からエラー証拠情報ノードＥ４に向かってリンクが生成されているものとする。この場合、診断モデル適正化部４７６は、プロセスＰ１，Ｐ２が、発生したエラー（エラー証拠情報ノードＥ４）の原因となると考えて、プロセスＰ１，Ｐ２をエラー証拠情報ノードＥ４に直接リンクさせる。

このような第２実施形態の仕組みによれば、エラーやワーニングをトリガとして取得したプロセスログＰＬ中のプロセスリストを原因としエラーやワーニングが結果となるサブ因果ネットワークが即座に既存（更新前）の診断モデルに組み込まれることになる。第１実施形態との比較では、バックトレースログＢＬとプロセスログＰＬの相違があるが、サブ因果ネットワーク生成部４７４で生成したサブ因果ネットワークを更新前の診断モデルに組み込むと言う点では大差がなく、第１実施形態と同様に製品出荷後のソフトウェア更新や新たな不具合に対して、診断モデルへの反映が迅速にかつ容易に行なわれることで、ソフトウェア診断性能が向上するようになる。

＜故障診断システム：第３実施形態＞
図１６は、複数台の画像形成装置１と通信回線を介して管理センタ４０１が接続されている故障診断システム４００の第３実施形態を示す図である。第３実施形態は、各画像形成装置１側でサブ因果ネットワークを生成・保持し、これを管理センタ４０１の診断サーバ部４０１Ａに送り、診断サーバ部４０１Ａにてサブ因果ネットワークに基づき診断モデルを適正化（更新）してから各画像形成装置１に送る仕組みとした点に特徴を有する。

構成的には、第１実施形態あるいは第２実施形態の診断条件制御部４６０を構成する機能部を、画像形成装置１側と管理センタ４０１（診断サーバ部４０１Ａ）側とに分けて配した態様となる。具体的には、エラー／ワーニング検出部４６２、ログ取得部４６４、呼出し関数グラフ生成部４７２（第２実施形態を基本とするときは不要）、および、サブ因果ネットワーク生成部４７４が画像形成装置１側に配置され、診断モデル適正化部４７６が管理センタ４０１（診断サーバ部４０１Ａ）側に配置される。

また、各画像形成装置１は、第１・第２実施形態の診断モデル適正化部４７６を除く機能部の他に、新たに、サブ因果ネットワーク生成部４７４が生成したサブ因果ネットワークを保持するサブ因果ネットワーク保持部４８２と、サブ因果ネットワーク保持部４８２に保持されているサブ因果ネットワークを所定のタイミングで（具体的には診断サーバ部４０１Ａからの要求があったときに）診断サーバ部４０１Ａに出力するサブ因果ネットワーク出力部４８４と、サブ因果ネットワークに基づいて適正化（更新）された適性診断モデルを診断サーバ部４０１Ａから受け取り、自装置の診断モデルとして適用する（つまり既存の診断モデルを更新する）適性診断モデル適用部４８６を備える。

また、診断サーバ部４０１Ａは、新たに、各画像形成装置１のサブ因果ネットワーク生成部４７４からサブ因果ネットワークを収集するサブ因果ネットワーク収集部４９２と、診断モデル適正化部４７６が適正化（更新）した適正診断モデルを各画像形成装置１に提示する診断モデル提示部４９４を備える。サブ因果ネットワーク収集部４９２は、各画像形成装置１から収集したサブ因果ネットワークを、たとえばハードディスク装置のようなストレージ部（たとえば診断モデルデータベース４０２ｂ）に保存する。

＜動作例：第３実施形態の概要＞
図１７は、第３実施形態の故障診断システム４００における診断条件適正化処理（故障診断モデル適正化処理）を説明する図である。ここで、図１７は第３実施形態の故障診断モデル適正化処理の手順を示すフローチャートである。ステップ番号を３００番台で示すとともに、第１・第２実施形態と同様の処理ステップには同一の１０番台および１番台の番号を付して示す。

各画像形成装置１においては、第１・第２実施形態と同様にして、ソフトウェアによって動作する画像形成装置１のソフトウェアの処理過程をログ記録部１６８で記録しておき（Ｓ３００）、エラーやワーニングの発生を契機としてログ取得部４６４によりバックトレースログＢＬやプロセスログＰＬを取得し（Ｓ３０２，Ｓ３０４）、これらログに基づいてサブ因果ネットワーク生成部４７４によりサブ因果ネットワークを生成する（Ｓ３２０）。サブ因果ネットワーク生成部４７４は、生成したサブ因果ネットワークをサブ因果ネットワーク保持部４８２に保持する（Ｓ３３０）。

診断サーバ部４０１Ａ（診断サーバ部４０１Ａ）のサブ因果ネットワーク収集部４９２は、定期的に通信網４０６を介して各画像形成装置１のサブ因果ネットワークを収集するべく、先ず、出力指示タイミングになると（Ｓ３３１−ＹＥＳ）、各画像形成装置１にサブ因果ネットワークの出力を指示する（Ｓ３３２）。この指示を受けた各画像形成装置１のサブ因果ネットワーク出力部４８４は、サブ因果ネットワーク保持部４８２に保持されているサブ因果ネットワークを読み出して通信網４０６を介して診断サーバ部４０１Ａに出力する（Ｓ３３４）。サブ因果ネットワーク収集部４９２は、各画像形成装置１から受け取った（収集した）サブ因果ネットワークを、ストレージ部に保持する（Ｓ３３６）。

診断モデル適正化部４７６は、サブ因果ネットワーク収集部４９２が各画像形成装置１から収集しストレージ部４９３に保持したサブ因果ネットワークを、第１・第２実施形態で説明した診断モデルの適正化処理と同様にして、既存（更新前）の診断モデルに組み込むことで診断モデルを診断対象装置に適合したものとなるようにする（Ｓ３６０）。このとき、診断モデル適正化部４７６は、第３実施形態に特有の処理として、サブ因果ネットワーク収集部４９２が収集した各サブ因果ネットワークを機種ごとに分類し（Ｓ３６１）、機種別に既存の診断モデルに組み込む。

診断モデル提示部４９４は、診断モデル適正化部４７６が適正化した（更新された）適正診断モデルを該当装置に提示する（Ｓ３７０）。診断サーバ部４０１Ａから適正化された適正診断モデルを受け取った画像形成装置１の適性診断モデル適用部４８６は、受け取った適性診断モデルを所定の記憶媒体（たとえば判定指標格納部２３０）に記憶することで、既存の診断モデルを更新し、受け取った適性診断モデルを適用した診断を行なう（Ｓ３８０）。

このような第３実施形態の仕組みによれば、エラーやワーニングをトリガとして取得したバックトレースログＢＬやプロセスログＰＬに基づいて各画像形成装置１で個別に生成したサブ因果ネットワークを、診断サーバ部４０１Ａの診断モデル適正化部４７６が纏めて既存の診断モデルに組み込むようになるため、ソフトウェア診断精度がさらに向上するようになる。各画像形成装置１で個別に保持しているソフトウェア障害情報を全て網羅した診断モデルを生成することになり、診断精度がさらに向上することになる。

以上、本発明について実施形態を用いて説明したが、本発明の技術的範囲は前記実施形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で前記実施形態に多様な変更または改良を加えることができ、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれる。

また、前記の実施形態は、クレーム（請求項）にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。前述した実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組合せにより種々の発明を抽出できる。実施形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られる限りにおいて、この幾つかの構成要件が削除された構成が発明として抽出され得る。

たとえば、上記実施形態では、複写機能、プリンタ機能、ファクシミリ機能、あるいはそれらの機能を組み合わせて有する複合機などの画像形成装置に、ソフトウェア障害の故障診断を行なう故障診断装置を適用した事例で示したが、ソフトウェア障害の故障診断を行なう故障診断装置が適用される装置は、画像形成装置に限らず、家電品や自動車などその他の任意の機器に適用してもよい。

故障診断装置の一実施形態を搭載した画像形成装置の構成例を示す図である。 故障診断装置の一実施形態を示すブロック図である。 電子計算機を利用して故障診断装置をソフトウェア的に実現する場合のハードウェア構成の一例を示すブロック図である。 故障確率推論部においてソフトウェア障害の故障診断時に利用するベイジアンネットワークの構成例を示すベイジアンネットワークモデル図である。 故障診断システムの第１実施形態（第１構成例）を示す図である。 故障診断システムの第１実施形態（第２構成例）を示す図である。 第１実施形態の故障診断システムにおける故障診断モデル適正化処理の手順を示すフローチャートである。 第１実施形態において適用されるエラー証拠情報ノードに関するバックトレースログの一例を示す図である。 エラー証拠情報ノードに関するバックトレースログから抽出した関数／モジュール記述リストの一例を示す図である。 エラー証拠情報ノードに関する呼出し関数グラフの一例を示す図である。 第１実施形態のサブ因果ネットワーク生成部によるサブ因果ネットワークの生成方法の具体例を説明する図である。 第１実施形態の診断モデル適正化部における診断モデル適正化処理の詳細を説明する図である。 故障診断システムの第２実施形態（第２構成例）を示す図である。 第２実施形態の故障診断システムにおける故障診断モデル適正化処理の手順を示すフローチャートである。 第２実施形態において適用されるエラー証拠情報ノードやワーニング証拠情報ノードに関するプロセスログの一例を示す図である。 第２実施形態の診断モデル適正化部における診断モデル適正化処理の詳細を説明する図である。 故障診断システムの第３実施形態を示す図である。 第３実施形態の故障診断システムにおける故障診断モデル適正化処理の手順を示すフローチャートである。

符号の説明

１…画像形成装置、１４０…動作状態情報取得部、１５２…故障情報取得部、１６０…診断情報収集部、１６８…ログ記録部、２３０…判定指標格納部、２６０…故障確率推論部、２６２…故障判定部、２６４…推論エンジン、３…故障診断装置、３Ａ…診断情報生成部、３Ｂ…故障診断部、４…センサ部、４００…故障診断システム、４０１…管理センタ、４０１Ａ…診断サーバ部、４０２…データベース部、４０２ａ…市場品質情報データベース、４０２ｂ…診断モデルデータベース、４０６…通信網、４１０…診断モデル生成・更新部、４１２…故障発生頻度算出部、４１９…確率表更新部、４２０…診断情報取得部、４２２…市場品質情報収集部、４２４…通信部、４３０…故障確率推論部、４６０…診断条件制御部、４６２…エラー／ワーニング検出部、４６４…ログ取得部、４６４Ａ…バックトレースログ取得部、４６４Ｂ…プロセスログ取得部、４７２…呼出し関数グラフ生成部、４７４…サブ因果ネットワーク生成部、４７６…診断モデル適正化部、４８２…サブ因果ネットワーク保持部、４８４…サブ因果ネットワーク出力部、４８６…適性診断モデル適用部、４９２…サブ因果ネットワーク収集部、４９４…診断モデル提示部

Claims (6)

1. 電子機器を動作させるソフトウェアの処理履歴を記録する記録手段と、
   前記電子機器に前記ソフトウェア処理を起因とする障害が発生したときに、前記障害の発生以前における前記ソフトウェアの処理履歴を前記記録手段から取得する取得手段と、
   前記取得手段により取得された前記処理履歴に基づいて、前記ソフトウェア処理を起因とする障害の１つまたは複数の原因モジュールに分類する分類手段と、
   前記分類手段により分類された原因モジュールのそれぞれを確率で関連付けたサブ因果ネットワークを生成する生成手段と、
   前記生成手段により生成されたサブ因果ネットワークを、既存の診断モデルの因果ネットワークに組み込んで前記既存の診断モデルを更新する更新手段と
   を有する故障診断装置。
2. 前記取得手段は、前記ソフトウェアの処理履歴として、前記障害の発生を通知したソフトウェアモジュールの関数の呼出しスタックを遡って出力したバックトレースログを取得し、
   前記取得手段が取得したバックトレースログから呼出し関数およびこの呼出し関数が含まれるソフトウェアモジュールを抽出し、呼出し関数およびソフトウェアモジュールの単位でグラフ化することで呼出し関数グラフを生成する呼出し関数グラフ生成部を
   さらに備え、
   前記生成手段は、前記関数グラフ生成部により生成された呼出し関数グラフのソフトウェアモジュールを前記サブ因果ネットワークのノードに割り当てるとともに、前記呼出し関数をそのノードのステートに割り当て、各ノードを呼出し関数の読出し順に基づいてリンクすることで前記サブ因果ネットワークを生成する
   請求項１に記載の故障診断装置。
3. 前記更新手段は、前記サブ因果ネットワーク生成部が生成したサブ因果ネットワークを既存の診断モデルの因果ネットワークと組み合わせるに当たり、
   既存の診断モデルの因果ネットワークに対して、前記サブ因果ネットワーク生成部が生成したサブ因果ネットワークのノード名とリンクを検索し、
   前記サブ因果ネットワークのノードが既存の診断モデルに存在するときにはステートの追加や確率値の更新を行ない、
   前記サブ因果ネットワークのノードが既存の診断モデルに存在しないときには、ノード，リンク，確率テーブルを追加する
   請求項２に記載の故障診断装置。
4. 前記取得手段は、前記ソフトウェアの処理履歴として、ソフトウェア処理システムのプロセスログを取得し、
   前記生成手段は、前記取得手段により取得されたプロセスログ中のプロセスリストを原因とし、前記障害の発生を結果とすることで、前記サブ因果ネットワークを生成する
   請求項１に記載の故障診断装置。
5. 前記生成手段により生成されたサブ因果ネットワークを保存するサブ因果ネットワーク保持部と、
   複数の電子機器の各サブ因果ネットワーク保持部に保持されているサブ因果ネットワークを所定のタイミングで収集するサブ因果ネットワーク収集部と
   をさらに備え、
   前記更新手段は、前記サブ因果ネットワーク収集部が収集した各電子機器のサブ因果ネットワークを機種ごとに分類して、機種別に既存の診断モデルに組み込む
   請求項１に記載の故障診断装置。
6. コンピュータを、
   電子機器を動作させるソフトウェアの処理履歴を記録する記録手段、
   前記電子機器に前記ソフトウェア処理を起因とする障害が発生したときに、前記障害の発生以前における前記ソフトウェアの処理履歴を前記記録手段から取得する取得手段、
   前記取得手段により取得された前記処理履歴に基づいて、前記ソフトウェア処理を起因とする障害の１つまたは複数の原因モジュールに分類する分類手段、
   前記分類手段により分類された原因モジュールのそれぞれを確率で関連付けたサブ因果ネットワークを生成する生成手段、
   前記生成手段により生成されたサブ因果ネットワークを、既存の診断モデルの因果ネットワークに組み込んで前記既存の診断モデルを更新する更新手段、
   として機能させるためのプログラム。
   

Images