JP2007279840A - 要因推定装置、要因推定方法、プログラムおよびコンピュータ読取可能記録媒体 - Google Patents

Abstract

【課題】 コストをかけることなく、適切な要因推定ができる要因推定装置を提供する。
【解決手段】 推論エンジンは、入力させる特徴を決定し（Ｓ１１）、入力ソース定義テーブルを参照して、特徴の入力を人にさせるかセンサにさせるかを決定する（Ｓ１２）。人に入力させるときは、ユーザに質問する内容をディスプレイに表示し、回答を入力させる（Ｓ１３，Ｓ１４）。センサからのデータを入力させるときは、言語変換部がセンサからセンサデータ入力部を介して情報を取得し、言語変換部がセンサからの数値データを言語値に変換する（Ｓ１５，Ｓ１６）。いずれかの処理によって入力されたデータに基づいて、推論エンジンが推論を行う（Ｓ１７）。これを、推論終了条件を満たすまで行い（Ｓ１８でＹＥＳ）、ＧＵＩがユーザに推論結果を表示する（Ｓ１９）。
【選択図】図６

Description

この発明は、要因推定装置、要因推定方法、プログラムおよびコンピュータ読取可能記録媒体に関し、特に、適切な要因推定ができる要因推定装置、要因推定方法、プログラムおよびコンピュータ読取可能記録媒体に関する。

従来から、製造工程等における不良の要因を推定する要因推定装置を用いた診断型エキスパートシステムが知られている。このようなエキスパートシステムでは、ユーザに所定の質問を行い、それに対するユーザからの回答を得る、といったユーザとの対話により、不良に関するデータの入力を受付けて、知識ベースを用いてその要因を推定している。しかしながら、ユーザのスキルによっては、適切な回答が入力できない場合があった。このような場合に対処するために、たとえば、特許第３５１１６３２号公報（特許文献１）では、データの入力を検査機のみから行っている。
特許第３５１１６３２号公報（段落番号０００９および図３等）

従来の、要因推定装置を用いたエキスパートシステムは上記のように構成されていた。特許文献１によれば、検査機からデータを入力していたが、このために、センサを必要とし、そのためにコストがかかるという問題があった。また、ユーザとの対話の代わりに、検査機からのデータで代用できる場合であっても、対象システムの相違や、センサやカメラ等のデータ検出装置の有無によって、異なる知識ベースや特徴抽出演算が必要になる場合があった。

この発明は、上記のような問題点に着目してなされたもので、コストをかけることなく、適切な要因推定ができる要因推定装置、要因推定方法、プログラム、およびプログラムを格納したコンピュータ読取可能記録媒体を提供することを目的とする。

この発明に係る、現象に関連する特徴量に対するデータに基づいて、前記現象に対する要因を推定する要因推定装置は、特徴量を決定する特徴量決定手段と、特徴量決定手段が決定した特徴量に対するデータとして、ユーザからの入力を受付けるユーザ入力手段と、特徴量決定手段が決定した特徴量に対するデータとして、データ取得装置からのデータを入力させる装置データ入力手段と、特徴量に対するデータをユーザ入力手段と装置データ入力手段のいずれから入力するかを予め定めた入力ソース定義手段と、入力ソース定義手段の定めた入力手段から入力されたデータを用いて要因を推定する推定手段とを含む。

所定の特徴量に対するデータをユーザ入力手段と装置データ入力手段のいずれから入力するかを、予め定めているため、要因を推定する対象システムの違いや、診断を行うユーザのスキルの違い等に応じて、適切に定めておけば、入力されたデータを用いて要因を推定するための適切なデータが得られる。
その結果、コストをかけることなく、適切な要因推定ができる要因推定装置を提供できる。

好ましくは、特徴量は複数存在し、推定手段は、複数の特徴量に基づいて要因を推定し、入力ソース定義手段は、複数の特徴量について、ユーザ入力手段と、装置データ入力手段のいずれの入力手段からのデータ入力を優先するかを予め定める優先順決定手段を含む。

さらに好ましくは、優先順決定手段は、両データ入力手段のそれぞれの入力データの信頼度を判断する信頼度判断手段をさらに含み、優先順決定手段は、信頼度判断手段の判断結果に応じて、ユーザ入力手段と、装置データ入力手段のいずれの入力手段からのデータ入力を優先するかを定める。

信頼度判断手段は、ユーザのスキルまたは役割から信頼度を判断してもよい。

入力ソース定義手段は、要因を推定する対象システムに応じて、複数の特徴量について、ユーザ入力手段と、装置データ入力手段のいずれの入力手段からのデータを入力するかを予め定めている。

この発明の一つの実施の形態によれば、対象システムは複数の運用フェーズで運用され、対象システムにおける、運用フェーズおよび使用可能な前記データ取得装置をユーザに入力させる運用フェーズ入力手段と、運用フェーズ入力手段に入力された運用フェーズおよびデータ取得装置を現象に対応させて格納する有効要因定義手段とを含む。

この発明の他の局面においては、エキスパートシステムは、上記の要因推定装置を含む。

この発明のさらに他の局面においては、現象に関連する特徴量に対するデータに基づいて、現象に対する要因を推定する要因推定方法は、特徴量に対するデータをユーザ入力装置、または、データ取得装置のいずれから入力するかを予め定めるステップと、特徴量を決定するステップと、予め定められたいずれかから特徴量に対するデータを入力させるステップと、入力されたデータを用いて現象に対する要因を推定するステップとを含む。

この発明のさらに他の局面においては、プログラムは、上記した要因推定方法をコンピュータに実行させる。

また、上記プログラムはコンピュータ読取可能記録媒体に格納されてもよい。

（１）第１実施の形態
以下、この発明の一実施の形態を、図面を参照して説明する。図１はこの発明の一実施の形態に係る要因推定装置の要部を示す機能ブロック図である。図１を参照して、要因推定装置１０は、たとえば、製造工程等で生じた不良等の現象に対する要因を、現象に関連する所定の特徴量に対するデータを用いて推定する装置である。図１を参照して、要因推定装置１０は、ユーザおよび、製造工程等に設けられたセンサ２３からのデータを受入るインターフェイスを有している。

要因推定装置１０は、ユーザとのインターフェイスとなるＧＵＩ（Graphic User Interface)１２と、ＧＵＩ１２に接続された入力部１３と、入力部１３に接続された推論エンジン１４と、推論エンジン１４に接続された知識ベース１６とを含む。入力部１３は、入力ソース定義テーブル１７、および言語値変換部１８に接続されている。推論エンジン１４は、知識ベース１６に基づいて製造工程等で生じた不良の要因の推定を行う。一方、センサ２３からのデータは、センサデータ入力部１９に入力され、言語値変換部１８で変換されて入力部１３に入力される。

言語値変換部１８は、センサデータ入力部１９に入力されたセンサ２３からのデータを推論エンジン１４が推論可能なデータに変換する。具体的には、たとえば、センサ２３からのデータが０．８であるとし、推論エンジン１４は、データがＨ（高い）かＬ（低い）か、を用いて推論するとする。このとき、言語値変換部１８は、所定の閾値を有しており、入力されたセンサデータ０．８をＨかＬのいずれかに変換する。

ＧＵＩ１２は、ユーザに対して画像を表示するためのディスプレイ等の表示部と、表示を見てユーザが入力するための、キーボードやマウスのような入力手段を含み、ユーザからの入力を受付けるユーザ入力手段（ユーザ入力装置）として機能する。

入力ソース定義テーブル（入力ソース定義手段）１７は、入力部１３に入力されるデータをＧＵＩ１２を介してユーザから受けるか、センサデータ入力部１９から受けるかを決定するためのテーブルである。なお、ＧＵＩ１２は、上記以外のファイルや音声インターフェイス等の入力機器による入力を受付けてもよい。

要因推定装置１０は、具体的には、ＣＰＵ１１を有するコンピュータであり、推論エンジン１４や言語値変換部１８はプログラムであり、知識ベース１６は図示のないハードディスク等の格納手段に格納されている。また、推論エンジン１４は特徴量決定手段および推定手段として機能する。

なお、以下では、このような、要因を推定する対象となるシステムを対象システムという。また、ここでは、対象システムからの入力として、図示のない検査装置の有するセンサ２３からの入力について説明するが、これに限らず、検査対象の画像を撮影するカメラ等を含む、データを取得可能な任意のデータ取得装置からのデータを入力してもよい。したがって、センサデータ入力部１９は、装置データ入力手段として機能する。

次に、図１に示した要因推定装置１０を用いて具体的に要因を推定する方法について説明する。要因推定装置１０は、ある製造工程等における不良要因を推定する、いわゆるエキスパートシステムとして作動する。エキスパートシステムには多くのものが存在するが、ここでは、電子部品実装装置の基板実装ラインにおける不良原因を特定する場合について説明する。

基板実装ラインを図２に示す。図２を参照して、基板実装ライン６０は、電子部品が実装される基板の流れる上流側から下流側に向かって配列された印刷（Print)工程と、マウント（Mount)工程と、リフロー（Reflow)工程とを含む。各工程間は、コンベヤ、ロボット、その他の搬送装置によって連結されている。各工程には、その工程の処理を行なうための装置が設けられている。

印刷工程には、基板のランドにはんだを印刷するための印刷機６１と、印刷後の検査を行なう印刷後検査装置６２とが設けられる。マウント工程には、基板に部品をマウントするためのマウンタ６３と、マウント後の検査を行なうマウント後検査装置６４とが設けられる。リフロー工程には、部品の端子をランドにハンダ付けをするためのリフロー炉６５とハンダ付け後の検査を行なうリフロー後検査装置６６とが設けられる。

印刷機６１、印刷後検査装置６２、マウンタ６３、マウント後検査装置６４およびリフロー炉６５およびリフロー後検査装置６６は、それぞれ、ＬＡＮ６７を介して要因推定装置１０および検査情報蓄積装置６８に接続されている。

印刷後検査装置６２、マウント後検査装置６４、リフロー後検査装置６６からは、それぞれの工程における検査結果が検査画像を含めて、検査情報蓄積装置６８に送られて格納され、必要に応じて、要因推定装置１０から読出される。

ここで、不良としては、ブリッジ（部品の電極間を短絡するようにハンダが付着すること）、濡れ不良（ハンダとランド、又は、ハンダと部品の電極との接合に不具合があること）、フィレット異常（ハンダ量が多すぎたり少なすぎたりして、ハンダを断面から見たときの輪郭線がきれいな山型になっていないこと）、および部品無し（部品が存在しないこと）等がある。

すなわち、ここでは、基板実装ラインに設けられた検査装置のセンサ２３からのデータ、または、カメラ等からの検査画像をユーザに見せてその判断結果を入力させて、要因の推定を行う。

次に知識ベース１６の内容について説明する。図３は、基板実装ラインにおける不良原因を特定する場合に用いられる、知識ベース１６の一例を示す図である。図３を参照して、ここでは、知識ベース１６は３層構造となっており、１層目は不良としての、生産ライン通過後の製品の不具合を表し、ここでは、「ブリッジ」が表示されている。２層目は不良の１次要因として生産途中の製品の異常現象、３層目は、１次要因の原因となる、２次要因として工程の装置や、使用する材料の異常を表現している。

次に、知識ベース１６の構造について説明する。図４（Ａ）は知識ベース１６の有するルールデータ３１を示す図であり、ここでは、たとえば、現象として「ブリッジ」（現象ＩＤがＰ０００１、図４（Ｂ）参照）と判断される場合の条件を列挙している。図４（Ａ）に示すように、ルールデータ３１は、特徴ＩＤがＴ０００１、Ｔ０００２、Ｔ０００３・・・等で表される、特徴量データを含むＩＦ〜ＴＨＥＮルールを有している。すなわち、ある特徴量の有無によって、その要因となる現象を推定できる。ここで、特徴ＩＤとは、不良のような現象に関連する特徴量を特定するものである。

図４（Ｂ）は現象データ３２を示す図である。この現象データが、要因推定装置１０における因果関係を表す要因を構成する。図４（Ｃ）は、図４（Ａ）で示した特徴量データの取得方法を示す図である。

図４（Ｃ）を参照して、各特徴量が特徴ＩＤで区別され、それぞれについて、特徴ＩＤ内連番、取得方法、ユーザに表示される選択肢とそのときユーザから入力されるデータの対、およびセンサ２３からの数値入力を言語値に変換するための閾値が含まれている。

特徴ＩＤ内連番については１が、各特徴ＩＤごとのデータの取得をユーザとの対話で行う場合であり、ユーザに対する質問の選択肢およびその入力が含まれている。なお、この入力は、閾値を超えたときはＴＲＵＥ、超えないときは、ＦＡＬＳＥとして計算する。また、特徴ＩＤ内連番２は、検査装置のセンサからのデータ入力であることを示している。

このように、一つの特徴量データの取得に、ユーザとの対話による入力と検査装置からのデータ入力による場合との２つの方法が準備されている。

図４（Ｄ）は、図４（Ｃ）で示した取得方法としての質問内容を図示のないディスプレイに表示した場合の例を示す図である。ここでは、図４（Ｃ）において、特徴ＩＤがＴ０００１の場合の質問画面が示されている。

図５は、図１において１７で示した入力ソース定義テーブル１７の内容を示す図である。図５に示すように、入力ソース定義テーブル１７は、特徴ＩＤごとに、特徴ＩＤ連番を用いて、入力ソースとして、ユーザ（人）から入力するのか、またはセンサ２３から入力するのか、いずれかを予め定めている。

図６はこの実施の形態における要因推定装置１０の動作（具体的には、ＣＰＵ１１の動作）を説明するフローチャートである。図６を参照して、要因推定部１０は、まず、推論エンジン１４が次に入力させる特徴を決定する（ステップＳ１１、以下、ステップを省略する）。したがって、推論エンジン１４は、特徴量決定手段として機能する。入力部１３が入力ソース定義テーブル１７を参照して、特徴の入力をユーザにさせるかセンサにさせるかを決定する（Ｓ１２）。

ユーザに入力させるときは、ＧＵＩ１２がユーザに質問する内容を図示のないディスプレイに表示し（Ｓ１３）、ユーザに提示した特徴量について回答を入力させる（Ｓ１４）。

センサ２３からのデータを入力させるときは、言語変換部１８がセンサ２３からセンサデータ入力部１９を介してデータを取得し（Ｓ１５）、言語変換部１８がセンサ２３からの数値データを言語値に変換する（Ｓ１６）。このセンサ２３からの入力は自動的に行われる。

いずれかから入力されたデータに基づいて、推論エンジン１４が推論を行う（Ｓ１７）。これを、推論終了条件を満たすまで行い（Ｓ１８でＹＥＳ）、ＧＵＩ１２がユーザに推論結果を表示する（Ｓ１９）。

このように、この実施の形態によれば、入力ソース定義テーブル１７の内容に応じて、ユーザかセンサかのいずれかからの特徴量に関するデータの入力を行い、その入力に応じて推論エンジン１４が要因を推定するようにしたため、対象システムの違いや、ユーザのスキルに応じて、予め入力するデータを定めておけば、適切な特徴量データが入力できる。その結果、不適切な入力による診断性能の低下を軽減させたり、入力するためのコストを削減できる。

なお、この入力ソース定義テーブル１７の入力ソースの決定には、対象システムにおける要因を推定する場合、製造した製品、材料、パラメータ、オペレータが行う調整、保守等を考慮して定めるのが好ましい。
（２）第２実施の形態
次にこの発明の第２実施の形態について説明する。この実施の形態においても要因推定装置１０の基本的な構成は図１に示した第１実施の形態と同様である。この実施の形態においては、複数の特徴量についてのデータを入力させ、それを組み合わせて要因を推定する。

この場合の入力ソース定義テーブル１７の例を図７に示す。図７を参照して、入力ソース定義テーブル１７は、特徴ＩＤごとに、特徴ＩＤ内連番で規定される２つの入力を有する。特徴ＩＤ内連番１は入力ソースとして人を規定し、特徴ＩＤ内連番２は入力ソースとしてセンサ２３からのセンサデータを規定する。さらにここでは、人とセンサデータのいずれを優先するかを優先度で規定している。たとえば、特徴ＩＤがＴ０００１であれば、センサデータが優先度１であり、人が優先度２であるから、センサデータが優先される。

図８はこの実施の形態におけるＣＰＵ１１が行う動作を示すフローチャートである。図８を参照して、この実施の形態においては、上記したように、データが複数入力される点が先の実施の形態と異なる。したがって、図８におけるＳ２１からＳ２６までの処理は、図６に示したＳ１１からＳ１６までの処理と同じであるため、その説明は省略する。

この実施の形態においては、Ｓ２４またはＳ２６からＳ２７に処理が移行したときに、複数の入力を得るため、必要な入力が得られたか否かを判断する。必要な入力が得られていないときは、処理はＳ２２へ移行し、次のデータを入力する。Ｓ２７で必要な入力を得たとき、入力部１３が入力された複数の言語値を統合し（Ｓ２８）、推論エンジン１４が推論を行う（Ｓ２９）。次いで、推論終了条件を満たしているか否かを判断し（Ｓ３０）、ＧＵＩ１２が推論結果を表示する。

このように、この実施の形態においては、複数の特徴量を用いて要因を推定するため、要因推定の精度が上がる。また、人からのデータの入力とセンサからのデータの入力との優先度が予め定められているため、適切に優先度を設定しておけば、要因推定の精度をさらにあげることができる。

次に、具体的な要因の推定方法について説明する。図９は、要因推定装置１０が電子部品実装装置における不良の一例としての「ブリッジ」を起こした場合の推論方法を説明する図である。図９（Ａ）は、図２に示した不良と１次要因を示す図であり、図９（Ｂ）は、１次要因を診断（推定）するための、ユーザに提示する質問文、およびその場合のユーザからの回答の例を示す図であり、図９（Ｃ）は、図９（Ｂ）に示した質問文とともに表示される、印刷工程等における検査画像である。この検査画像は、図２に示した検査情報蓄積装置６８に格納されており、そこから必要に応じて取り出される。なお、知識ベース１６に直接格納してもよい。このように、ユーザからの情報を得るときは、検査装置からの検査画像等を表示しながら行う。これによって、正確な情報が入力され、的確な推論が行われる。

図９（Ｂ）を参照して、ここでは、特徴量に関する質問ＩＤ２および６について有意な回答が得られている。これらの回答から推論エンジン１４は、不良（ブリッジ）に対応する１次要因は、図９（Ａ）において太線で示されているものである、と推論する。すなわち、ブリッジの要因の可能性があるのは、「印刷後はんだのにじみ」か、「実装後はんだの押しつぶし」を起こした２次要因のみに絞り込まれる。

図１０は、２次要因を特定する方法を示す図である。図１０（Ａ）は、図９で示した要因の可能性がある一例としての「印刷後はんだのにじみ」がある場合の特徴量を示す図であり、図１０（Ｂ）は、この段階で使用される、ユーザに提示する質問文、およびその場合のユーザからの回答例を示す図である。図９の場合と同様に、検査画像から特徴量に関する質問ＩＤＡ〜Ｄの質問に対してユーザが回答を入力する。入力された回答から、質問ＩＤＡ、およびＣが関係することがわかる。したがって、これらの関係する「印刷機マスク破損あり」、「印刷機基板厚さ設定間違い」および「印刷機印圧設定高い」が２次要因であると判断される。

図１１は、図９で特定されたもう一つのブリッジの要因の可能性である、「実装後はんだの押しつぶし」の２次要因を特定する方法を示す図である。図１１（Ａ）は、「実装後はんだの押しつぶし」がある場合の特徴量（２次要因）を示す図であり、図１１（Ｂ）は、この段階で使用される、ユーザに提示する質問文、およびその場合のユーザからの回答例を示す図である。図１０の場合と同様に、検査画像から特徴量に関する質問ＩＤＦ〜Ｊの質問に対してユーザが回答を入力する。入力された回答から、質問ＩＤＦ、ＩおよびＪが関係することがわかるため、これらに関連する「マウンタノズルつまり」が２次要因であると判断される。

以上から、推論エンジン１４は、「印刷機マスク破損あり」、「印刷機基板厚さ設定間違い」、「印刷機印圧設定高い」および、「マウンタノズルつまりあり」の５個が「ブリッジ」の要因の可能性が高いと推定する。

さらに、人の判断、センサデータだけでなく、たとえば、カメラによる画像判断のように、３つ以上の入力がある場合は、それぞれの入力に優先度を定めて最も優先度の高い入力を採用してもよい。また、優先度を利用するのではなく、これらの入力データの多数決で判断し、多いほうの結果をその特徴量に対する判断としてもよい。たとえば、上記で、印刷後はんだのずれ（特徴ＩＤＴ０００１）について、人の判断、センサデータを変換した言語値のうち、最もメンバシップグレードが大きいもの、カメラによる画像判断それぞれが、「ＦＡＬＳＥ」、「ＴＲＵＥ」、「ＦＡＬＳＥ」を示した場合は「ＦＡＬＳＥ」と判断される。

さらに、センサ２３が複数、たとえば、２個設けられている場合に、１つのセンサからは０．８という値が得られ、他方のセンサからは０．７という値が得られたときは、これらのデータの平均値を求め、これをセンサデータとしてもよい。すなわち、複数のデータについて、予めそれらのデータの統合方法（この場合では平均値とする）を定めておき、その統合方法にしたがってデータを統合したものを入力データとしてもよい。
（３）第３実施の形態
次にこの発明の第３実施の形態について説明する。この実施の形態においても要因推定装置１０の基本的な構成は図１に示した第１実施の形態と同様である。この実施の形態においては、ユーザから入力された情報、または、検査装置から検知した情報に基づいて、ユーザからのデータを入力するか、センサデータを入力するかを判断する。

たとえば、入力部１３は、ユーザに対して、ユーザのスキルや、センサやカメラ等のデータ取得装置が備えられているかいないか、等を問合せ、その結果によって、データ取得装置が備えられているものについては、自動的に（または優先的に）そこから入力し、データ取得装置が備えられていないときは、ユーザからの入力とする。このとき、入力部１３は優先順決定手段として機能する。

この場合の入力ソース定義テーブル１７を作成するための、ディスプレイに表示されたユーザに対する問合せ画面を図１２（Ａ）に示す。図１２（Ａ）を参照して、ユーザに対して、「利用できる検査装置情報および装置情報を入力してください」という表示とともに、基板実装ラインに、以下の各検査装置が設けられているか否かを問い合わせる。すなわち、印刷後検査装置（検査画像）、印刷後検査装置（検査数値データ）、マウント後検査装置（検査画像）、マウント後検査装置（検査数値データ）、リフロー後検査装置（検査画像）、リフロー後検査装置（検査数値データ）が設けられているか否かを問い合わせる。また、装置情報として、マウンタＡ、マウンタＢが設けられているか否かを問い合わせる。ここでは、各検査装置等がボックス付きで表示され、ユーザが利用可能な検査装置情報および装置情報をそのボックスを選択することによって入力する。

このように利用可能な検査装置等が入力されると、ＣＰＵ１１は、これに基づいて、図１２（Ｂ）に示す、利用可能データを示す入力ソース定義テーブル１７を作成する。この場合、検査装置のようなデータ取得装置が備えられているものについて優先的にそこから入力し、検査装置が備えられていないときは、ユーザからの入力とする。このときは、ＣＰＵ１１は優先順決定手段として機能する。

図１２（Ｂ）を参照して、入力ソース定義テーブル１７は、各特徴ＩＤごとに、特徴ＩＤ内連番、優先順、入力ソースとともに、図１２（Ａ）で入力された、利用可能な検査装置等が○印で表示されている。これによって、利用可能なセンサデータ等が明瞭になり、機器構成によって、人からのデータと、センサからのデータとのいずれを優先して取り入れるべきかをより確実に判断できる。

次にこの場合の動作について説明する。図１３は、この実施の形態におけるＣＰＵ１１が行う動作を示すフローチャートである。図１３を参照して、この実施の形態においては、まず、入力部１３がＧＵＩ１２から図１２（Ａ）に示した検査装置情報等を取得する（Ｓ４１）。推論エンジン１４が次に入力させる特徴を決定する（Ｓ４２）。入力部１３が入力ソース定義テーブル１７から入力ソースを決定する（Ｓ４３）。

入力部１３が入力ソース定義テーブル１７を参照して、特徴の入力を人にさせるか、センサにさせるかを決定する（Ｓ４４）。人からの入力であれば、ＧＵＩ１２がユーザに質問を提示し、ユーザに提示した特徴量について回答を入力させる（Ｓ４５、Ｓ４６）。一方、センサ２３からの入力であれば、言語変換部１８がセンサ２３から情報を取得し、センサ２３からの数値入力を言語値に変換する（Ｓ４７、Ｓ４８）。

いずれかからのデータによって、推論エンジン１４は推論を行う。そして、推論終了条件を満たせば（Ｓ５０でＹＥＳ）、ＧＵＩ１２が推論結果を表示する（Ｓ５１）。推論終了条件を満たしていなければ（Ｓ５０でＮＯ）、Ｓ４３へ移行する。

なお、上記実施の形態においては、ユーザに対して、検査装置の有無や、マウンタの情報を入力させたが、これに限らず、ユーザのスキルを入力させてもよい。

この場合は、優先度の設定を、たとえば、ユーザのスキルによって変更できる。すなわち、ユーザ（人）が基板実装ラインのリーダ等であれば、そのスキルは十分信頼に値するため、センサデータよりも人の判断を優先させる。一方で、ユーザが、たとえば、製造ラインの一工程のみを担当するオペレータであれば、そのスキルについては、あまり信頼がおけないため、センサデータを優先する。このとき、ＣＰＵ１１は、信頼度判定手段として機能する。

また、ユーザの権限や、ユーザの役割等によって優先順を変えてもよい。ユーザの権限としては、たとえば、製造ラインの一工程のみを担当するオペレータ権限や、製造ラインのリーダ権限等が存在する。ユーザの役割としては、設計担当者や生産技術者が存在する。これらによってもそのスキルや知識が異なる。そこで、それらのデータを予め入力させ、それによって、どの現象の判断はユーザからの入力を優先するのか、検査装置からのデータを優先するのかを定めてもよい。

さらに、要因推定装置１０が要因を推定する対象システムの種類を入力させ、それに応じて、複数の入力を組み合わせてもよい。

このようにすれば、ユーザのスキルのレベルや、対象システムの種類によって入力先を変えることができるため、より適切なデータ入力が可能になる。

なお、利用できる検査装置等の情報については、要因推定装置１０がこれを自動的に検出するようにしてもよい。
（４）第４実施の形態
次に、この発明の第４実施の形態について説明する。上記各実施の形態においては、要因推定装置に入力されるデータを人から入力させるか、センサから入力させるかを選択させたが、第４実施の形態においては、この入力のために、ユーザへ表示する内容を切替える。具体的には、要因推定装置が要因を推定する対象システムの運用フェーズによって、着目する要因が異なる点に鑑みて、運用フェーズに応じて、ユーザへ出力する内容を切替える。

図１４はこの発明の第４実施の形態に係る要因推定装置２０の要部を示す機能ブロック図である。図１４を参照して、この実施の形態に係る要因推定装置２０は、図１に示した要因推定装置１０に対して、有効要因定義テーブル１５が推論エンジン１４に追加されている。それ以外は、図１に示した要因推定装置１０と基本的に同じであるので、これ以外の点については、同一部分に同一参照番号を付してその説明を省略する。

要因を推定する対象システムは、複数の運用フェーズで運用される。有効要因定義テーブル（有効要因定義手段）１５は、どの運用フェーズのときにどの要因を出力するのか等のデータを有している。なお、運用フェーズとは、製造システムにおいては生産段階のことをいい、試作フェーズ、量産フェーズ等を含む。

有効要因定義テーブル１５およびそれを作成するための、対象システムにおける運用フェーズおよび使用可能なデータ取得装置をユーザに入力させる問合せ画面を図１５に示す。図１５（Ａ）は、生産フェーズ等の入力画面を示す。生産フェーズ等としては、予めユーザがこの画面を通じて定めることができる。図１５（Ａ）を参照して、この入力画面は、利用できる生産フェーズ情報、装置情報の入力を促す表示に加えて、選択ボックスと、各フェーズが表示されている。ユーザは、この画面から利用可能なフェーズを入力する。

ここで、生産フェーズには、試作フェーズ、量産フェーズがあり、マウンタの装置情報としてマウンタＡ、マウンタＢが表示されている。生産フェーズにマウンタが含まれているのは、どのマウンタを使用するかによって、使用できる情報が異なるためである。

図１５（Ａ）で入力されたデータに基づいて、図１５（Ｂ）に示す有効要因定義テーブル１５を作成する。有効要因定義テーブル１５は、入力された運用フェーズおよびデータ取得装置を現象に対応させて格納した表である。

したがって、ＧＵＩ１２は、対象システムにおける運用フェーズおよびデータ取得装置をユーザに入力させる運用フェーズ入力手段として機能する。

なお、ここでは、運用フェーズとして、製造装置における生産フェーズについて説明したが、これに限らず、要因を推定する対象システム等に応じて異なり、種々の運用フェーズを含んでもよい。

次にこの実施の形態におけるＣＰＵ２１の動作について説明する。図１６は、この実施の形態における動作を説明するためのフローチャートである。図１６を参照して、入力部１３がＧＵＩ１２からシステムの運用フェーズなどの情報を取得する（Ｓ６１）。推論エンジン１４が運用フェーズ等の情報から出力する要因を決定する（Ｓ６２）。次いで、推論エンジン１４が次に入力させる特徴を決定する（Ｓ６３）。入力部１３が入力ソース定義テーブル１７から入力ソースを決定する（Ｓ６４）。入力部１３が入力ソース定義テーブル１７を参照して特徴の入力を人にさせるかセンサ２３にさせるかを決定する。人に入力させるときは、ＧＵＩ１２がユーザに質問を提示し、ユーザに提示した特徴量について回答を入力させる（Ｓ６６、Ｓ６７）。

センサ２３から入力する場合は、言語変換部１８がセンサ２３から情報を取得し、言語変換部２３がセンサ２３からの数値入力を言語値に変換する（Ｓ６８、Ｓ６９）。

推論エンジン１４が推論を行い（Ｓ７０）、推論終了条件を満たしているか否かを判断し（Ｓ７１）、満たしていれば（Ｓ７１でＹＥＳ）、ＧＵＩ１２が推論結果を表示する（Ｓ７２）。Ｓ７１で推論終了条件を満たしていなければ（Ｓ７１でＮＯ）、Ｓ６３へ戻って次のデータを入力させる。

なお、推論エンジン１４が運用フェーズ等の情報から出力する要因を決定する処理（Ｓ６２）は、Ｓ７０の後、または、Ｓ７２の前に行ってもよい。

以上のように、この実施の形態によれば、システムの運用フェーズによってユーザに出力する内容を切替えたため、システムの運用フェーズに応じた要因推定のためのデータ入力が可能になる。

次に、上記実施の形態において出力する要因を切替える場合に、着目する内容について説明する。

図１７は、有効要因定義テーブル１５における特徴量、または要因の切替えを説明するための図である。図１７（Ａ）は、有効要因定義テーブルの一例４３のデータ構造を示す図である。これは基本的に図１５（Ｂ）に示したものと同じである。ここでは有効要因定義テーブル４３は、製造ラインとそのフェーズ４４ごとに、生産フェーズと装置情報とを含む情報４５が含まれているが、これ以外に、後に説明する、現象ＩＤや、特徴ＩＤや、優先順のデータを有している。

図１７（Ｂ）は、図１７（Ａ）から現象ＩＤと生産フェーズと装置情報とを含む情報４５とを取り出して、現象と生産フェーズ、装置情報との関係を表す対応表を作成した状態を示す図である。この図は、図１５（Ｂ）に対応する。

一方、図１７（Ｃ）は、特徴ＩＤごとに、特徴ＩＤ内連番、優先順、取得可能な検査データが表示されている。すなわち、ここでは、特徴ＩＤと、検査データとの対応が一覧でわかるように表示されている。

すなわち、有効要因定義テーブル４３を図１７（Ａ）に示すように、多くの関連情報を含むように構成することによって、そこから、特徴量や要因の切替えを行うための情報が共通の情報を必要に応じて取り出して、必要な有効要因定義テーブル１５を作成できる。

このようにすることによって、図１５で説明した例では、利用できる検査装置が存在する生産フェーズを個別に選択する必要があったが、ここでは、この表から関連するデータを取り出すことによって、図１５（Ａ）に対応する表を容易に作成できる。

次に、有効要因定義テーブル１５を用いて、ルールデータや、特徴ＩＤと、検査データとの対応が一覧でわかる表を編集する方法について説明する。図１６に示したように、ＧＵＩ１２から、ユーザに、たとえば、生産フェーズ、検査装置情報、装置情報を入力させる。生産フェーズは試作フェーズであり、印刷後検査装置（検査画像、これは検査画像を検出可能な検査装置を意味する）を有し、マウンタＡが使用されると入力されたものとする。

入力された情報から入力ソースを切替えて最終的な出力となる要因を絞る。

図１８（Ａ）は、この場合の有効要因定義テーブル１５を示す図であり、図１５（Ｂ）と同様の図である。図１８（Ａ）において、入力された試作フェーズ、マウンタＡから、これらの情報を有する現象ＩＤ（Ｐ０３０１およびＰ０３０２）５１ａは使用可能であるが、これらの情報を有しない現象ＩＤ（Ｐ０３０３およびＰ０３０４）５１ｂは使用できない。したがって、図１８（Ｂ）に示すように、ルールデータ５２において、使用可能な現象ＩＤ（Ｐ０３０１およびＰ０３０２）を導くルール５２ａは、使用可能として残すが、使用できない現象ＩＤ（Ｐ０３０３およびＰ０３０４）を導くルール５２ｂは、使用できないため削除する。

同様に、図１８（Ｃ）を参照して、印刷後検査装置（検査画像）を有する特徴ＩＤ５３ａ（Ｔ０００１で特徴内連番１）および特徴ＩＤ５４ａ（Ｔ０００２で特徴内連番１）は使用可能であるが、印刷後検査装置（検査画像）を有さない特徴ＩＤ５３ｂ（Ｔ０００１で特徴内連番２）および特徴ＩＤ５４ｂ（Ｔ０００２で特徴内連番２）は使用できないため、削除する。

このように、要因推定を行う対象システムに応じた、検査装置情報や、装置情報をユーザに入力させ、それに応じて、必要な有効要因定義テーブル１５を作成できる。

なお、上記実施の形態においては、対象システムの運用フェーズによって、出力する要因を切替えて必要な有効要因定義テーブルを作成する例について説明したが、これに限らず、上記したユーザの役割や、権限によって、出力する要因を切替えてもよい。

また、要因に対応する対策にかかるコストに応じて切替えてもよい。これは、たとえば、ある要因の対策として、１時間かかる対策Ａと５分で処理できる対策Ｂとがあったときに、要因対策にかかる時間やコストによって、出力する要因を切替えてもよい。

なお、上記実施の形態では、この発明に係る要因推定装置が、基板実装装置における不良内容の原因を推定する装置に適用された場合について説明したが、これに限らず、任意の装置における所望の要因の推定装置に適用されてもよい。

また、上記実施の形態においては、要因推定装置がその専用装置である場合について説明したが、これに限らず、装置を汎用のパソコンとし、上記の動作を全てプログラム化して、パソコンをそのプログラムで作動させて要因推定装置として使用してもよい。この場合、このプログラムは、光ディスクやハードディスクのような記録媒体で提供してもよいし、ネットワークを介して、ネット上のサーバからダウンロードするようにしてもよい。

以上、図面を参照してこの発明の実施形態を説明したが、この発明は、図示した実施形態のものに限定されない。図示された実施形態に対して、この発明と同一の範囲内において、あるいは均等の範囲内において、種々の修正や変形を加えることが可能である。

この発明の一実施の形態に係る要因推定装置の機能ブロック図である。 基板実装ラインを示す図である。 基板実装ラインをにおける不良原因を特定する場合に用いられる、知識ベースの一例を示す図である。 知識ベースの内容を示す図である。 入力ソース定義テーブルを示す図である。 第１実施の形態における要因推定装置の動作を示すフローチャートである。 入力ソース定義テーブルを示す図である。 第２実施の形態における要因推定装置の動作を示すフローチャートである。 「ブリッジ」を起こした場合の推論方法を説明する図である。 １次要因を特定する方法を示す図である。 ２次要因を特定する方法を示す図である。 入力ソース定義テーブルを示す図である。 第３実施の形態における要因推定装置の動作を示すフローチャートである。 第４実施の形態に係る要因推定装置の機能ブロック図である。 有効要因定義テーブルを示す図である。 第４実施の形態における要因推定装置の動作を示すフローチャートである。 特徴量または要因の切替えを説明するための図である。 有効要因定義テーブルを示す図である。

符号の説明

１０，２０ 要因推定装置、１１，２１ ＣＰＵ、１２ ＧＵＩ、１３ 入力部、１４ 推論エンジン、１５ 有効要因定義テーブル、１６ 知識ベース、１７ 入力ソース定義テーブル、１８ 言語値変換部、１９ センサデータ入力部、２３ センサ。

Claims (10)

1. 現象に関連する特徴量に対するデータに基づいて、前記現象に対する要因を推定する要因推定装置であって、
   前記特徴量を決定する特徴量決定手段と、
   前記特徴量決定手段が決定した特徴量に対するデータとして、ユーザからの入力を受付けるユーザ入力手段と、
   前記特徴量決定手段が決定した特徴量に対するデータとして、データ取得装置からのデータを入力させる装置データ入力手段と、
   前記特徴量に対するデータを前記ユーザ入力手段と前記装置データ入力手段のいずれから入力するかを予め定めた入力ソース定義手段と、
   前記入力ソース定義手段の定めた入力手段から入力されたデータを用いて前記要因を推定する推定手段とを含む、要因推定装置。
2. 前記特徴量は複数存在し、前記推定手段は、前記複数の特徴量に基づいて前記要因を推定し、
   前記入力ソース定義手段は、前記複数の特徴量について、前記ユーザ入力手段と、前記装置データ入力手段のいずれの入力手段からのデータ入力を優先するかを予め定める優先順決定手段を含む、請求項１に記載の要因推定装置。
3. 前記優先順決定手段は、前記ユーザ入力手段と、前記装置データ入力手段とのそれぞれの入力データの信頼度を判断する信頼度判断手段をさらに含み、
   前記優先順決定手段は、前記信頼度判断手段の判断結果に応じて、前記ユーザ入力手段と、前記装置データ入力手段のいずれの入力手段からのデータ入力を優先するかを定める、請求項２に記載の要因推定装置。
4. 前記信頼度判断手段は、ユーザのスキルまたは役割から信頼度を判断する、請求項３に記載の要因推定装置。
5. 前記入力ソース定義手段は、前記要因を推定する対象システムに応じて、前記複数の特徴量について、前記ユーザ入力手段と、前記装置データ入力手段のいずれの入力手段からのデータを入力するかを予め定めている、請求項１から４のいずれかに記載の要因推定装置。
6. 前記対象システムは、複数の運用フェーズで運用され、
   前記対象システムにおける、前記運用フェーズおよび使用可能な前記データ取得装置をユーザに入力させる運用フェーズ入力手段を含み、
   前記運用フェーズ入力手段に入力された運用フェーズおよび前記データ取得装置を前記現象に対応させて格納する有効要因定義手段を含む、請求項５に記載の要因推定装置。
7. 請求項１から６に記載の要因推定装置を含む、エキスパートシステム。
8. 現象に関連する特徴量に対するデータに基づいて、前記現象に対する要因を推定する要因推定方法であって、
   特徴量に対するデータをユーザ入力装置、または、データ取得装置のいずれから入力するかを予め定めるステップと、
   特徴量を決定するステップと、
   予め定められたいずれかから特徴量に対するデータを入力させるステップと、
   入力されたデータを用いて現象に対する要因を推定するステップとを含む、要因推定方法。
9. 請求項８に記載された要因推定方法をコンピュータに実行させるプログラム。
10. 請求項９に記載されたプログラムを格納したコンピュータ読取可能記録媒体。