基板生産ラインにおける目視確認処理の管理方法、およびこの方法を用いた基板生産ラインの管理用サーバ装置
【課題】目視確認のためにラインが停滞するのを解消する。
【解決手段】情報収集処理部３０５は、各工程の製造装置１および検査装置２から、所定の時間毎に、管轄する基板の基板状況データおよび検査結果を取り込んで、データベース３０２，３０３を書き換える。処理開始時刻予測部３０６は、各工程で搬送中および待機中の基板について、データベース３０１，３０２を用いて次の工程の処理が開始される時刻を算出する。確認待ち行列生成部３０７は、データベース３０３を用いて、各工程で不良と判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを、処理開始予定時刻が早い基板に対応するものから順に並べたデータ列を作成する。割当処理部３０９は、端末装置４との通信により、処理が可能な端末装置４を認識し、その装置にデータ列の先頭のコマンドを送信する。
【解決手段】情報収集処理部３０５は、各工程の製造装置１および検査装置２から、所定の時間毎に、管轄する基板の基板状況データおよび検査結果を取り込んで、データベース３０２，３０３を書き換える。処理開始時刻予測部３０６は、各工程で搬送中および待機中の基板について、データベース３０１，３０２を用いて次の工程の処理が開始される時刻を算出する。確認待ち行列生成部３０７は、データベース３０３を用いて、各工程で不良と判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを、処理開始予定時刻が早い基板に対応するものから順に並べたデータ列を作成する。割当処理部３０９は、端末装置４との通信により、処理が可能な端末装置４を認識し、その装置にデータ列の先頭のコマンドを送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各自動外観検査装置（以下、単に「検査装置」という場合もある。）による検査結果を確認する技術に関する。特にこの発明は、検査装置で不良と判定された被検査部位の画像を、本当に不良であるかどうか目視により判断するために、複数人の係員に行わせる目視確認処理を管理する方法、およびこの方法を実施するサーバ装置に関する。
【背景技術】
【０００２】
部品実装基板の生産ラインには、一般に、クリームはんだの印刷工程、部品の実装工程、およびリフロー工程の３種類の工程が含まれる。また工程毎に自動外観検査装置を設け、処理後の基板を検査してから後続の工程に流すようにしたラインについて、検査に使用された画像を検査結果とともにモニタに表示して、係員による確認作業を行えるようにした基板検査システムも提案されている（特許文献１参照）。
【０００３】
ただし自動検査を行う場合には、判定基準値の設定によって、実際は不良でないのに不良と判定されることがある（以下、この誤判定を「見過ぎ」と呼ぶ。）。このため、従来の基板生産ラインには、各自動検査装置に専用の端末装置を接続し、この端末装置に不良と判定された被検査部位の画像を送信して、係員による目視確認を行うものがある（特許文献２の段落０００３，図７参照）。
【０００４】
【特許文献１】特開２００５−３０３２６９号公報
【特許文献２】特許第３７２４８５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
不良判定部位の目視確認を行う場合には、最終工程以外の工程で不良判定がなされても、「見過ぎ」と判断されれば、不良と判定された基板を取り除かずに次の工程に搬送するので、そのまま次の工程の処理を進めることができる。しかし、この方法では、目視確認が終了するまで次の工程を実行せずに待機する必要があるため、不良判定部位が増えたり、確認作業の時間が長くなったりすると、処理待ちの基板が増えてラインが停滞するおそれがある。
【０００６】
また、従来の確認作業では、ラインや工程毎に目視確認の担当者が割り振られているので、あるラインで多数の不良判定部位が発生した場合、他のラインの担当者が手すきの状態であっても、不良判定部位が発生したラインの担当者のみで対応しなければならず、その結果、その担当のラインのみが停滞することがあった。
【０００７】
この発明は上記の問題に着目してなされたもので、不良判定部位の目視確認のためにラインが停滞したり、目視確認の担当者の負荷にばらつきが生じるのを解消し、基板生産ラインを効率良く稼動させることを、課題とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するための基板生産ラインにおける目視確認処理の管理方法では、各工程の製造処理部、およびライン外に配備される複数の端末装置を、それぞれ共通のサーバ装置に接続し、各製造処理部は、管轄する基板の処理状況データおよび検査結果データをサーバ装置に送信する処理を、各端末装置は、自装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データをサーバ装置に送信する処理を、それぞれ繰り返し実行し、サーバ装置において、下記のステップＡ、Ｂ，Ｃ，Ｄを実行するようにしている。
【０００９】
ステップＡでは、各製造処理部から送信された検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する。ステップＢでは、各工程における処理時間および工程間における基板の搬送時間、ならびに各製造処理部から送信された各基板の処理状況データに基づき、ステップＡで認識された基板毎に、次の工程の処理が開始されるタイミングを予測する。なお、この予測処理は、たとえば「次の工程が開始される時刻」または「次の処理が開始されるまでの待ち時間」を算出する処理として、実行される。
【００１０】
ステップＣでは、不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドをステップＢで予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成する。
【００１１】
ステップＤでは、各端末装置から送信された稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、ステップＣで生成したデータ列の先頭部分の確認要求コマンドを送信する。なお、「先頭部分の確認要求コマンド」は１つに限らず、複数のコマンドをまとめて送信してもよい。
【００１２】
上記の方法において、製造処理部や端末装置からサーバ装置へのデータ送信は、たとえば、一定の時間が経過する毎に実行しても良い（すなわち、定期的なデータ送信）が、これに限らず、新たなデータが発生する都度、行ってもよい（すなわち、不定期のデータ送信）。また、サーバ装置からのデータ送信要求に応じて、その時点で保持するデータを送信するようにしてもよい。
【００１３】
サーバ装置は、１台のコンピュータにより構成することができるが、これに限らず、複数台のコンピュータによるネットワークシステムとして構成してもよい。
【００１４】
上記のステップＡでは、最終工程以外の工程の製造処理部で不良と判定された基板を認識すれば良いが、これに限らず、全工程での不良判定基板を認識してもよい。ただし、この場合、最終工程で不良判定された基板については、ステップＢ，Ｃの対象とせず、その他の工程で不良と判定された基板に対する確認要求コマンドの送信が終了してから、確認要求コマンドの設定や送信を行うようにしてもよい。
【００１５】
各製造処理部からの処理状況データは、管轄する基板およびその基板に対する処理状況を表すものである。たとえば、管轄に入った基板の識別データと、その基板の現在の処理状況を示すデータ（待機中、処理中、処理済みなど）とを組み合わせたものとなる。
【００１６】
検査結果データは、検査が行われた基板およびその検査結果を表すものである。たとえば、検査が行われた基板の識別データと良否を示すデータ（ＯＫ／ＮＧ）とを組み合わせたものとなる。さらに個々の被検査部位のうち、少なくとも不良と判定された部位について、その部位の識別データや不良の内容を示すデータが検査結果データに含まれるのが望ましい。
【００１７】
確認要求コマンドは、どの基板のどの部位の画像を目視確認の対象とするかを示すものであるのが望ましい。たとえば、確認対象の不良判定部位を特定するデータ（たとえば、基板および不良判定部位の識別データの組み合わせ）、もしくはこの部位の画像を呼び出すためのデータ（たとえば、画像格納場所のアドレスや画像ファイル名など）を含むデータを、確認要求コマンドとする。
【００１８】
上記の方法によれば、不良と判定された基板を、次の工程の処理が開始されるタイミングが早い順に、目視確認処理を割り当てることができる。すなわち、確認処理を急ぐ必要がある基板から順番に、処理が可能な端末装置による確認作業を行うことが可能になるから、係員の負荷がばらつくのを防止して、効率良く、目視確認作業を進めることができる。
【００１９】
上記方法の好ましい態様では、ステップＢにおいて、最終の工程を除くいずれかの工程の検査装置で不良と判定されて次の工程に搬送される基板があるとき、次の工程の製造処理部から送信された処理状況データに基づき、当該次の工程が管轄する先行の基板の処理に要する時間を求め、次の工程に搬送される基板について、その搬送に要する時間から当該基板が次の工程の管轄に入る時刻を割り出し、その時刻から先行の基板の処理に要する時間が経過した時点の時刻を、次の工程の処理が開始される時刻として設定する。よって、複数のラインまたは工程において、同じ時期に不良判定が行われた場合でも、次の工程での処理待ち時間が少ないものから優先的に目視確認が行われるので、目視確認作業のために次工程の処理開始が遅くなるのを防止することができる。
【００２０】
さらに好ましい態様では、サーバ装置は、確認要求コマンドを送信した端末装置から、そのコマンドに対する目視確認結果を受け付けるステップＥと、このステップＥで受け付けた目視確認結果が不良である旨を示すとき、前記データ列から同一の基板に対応する確認要求データを削除するステップＦとを、さらに実行する。
【００２１】
上記の態様は、目視確認処理で「不良」と判断された基板がラインから取り除かれる場合に有用である。１枚の基板に複数の不良判定部位がある場合には、これらの部位毎に確認要求コマンドが設定されるが、これら不良判定部位のうちの１つが目視により「不良」と判断されると、残りの不良判定部位に対応する確認要求コマンドはすべてデータ列から削除される。よって、他の不良判定部位の確認要求データが繰り上げられ、目視確認作業の開始タイミングを早めることが可能になる。
【００２２】
上記の方法を実行する管理用のサーバ装置は、各ラインの各工程の製造処理部から、それぞれその処理部が管轄する基板の処理状況データおよび検査結果データを収集する処理を、繰り返し実行する第１の情報収集手段；各端末装置から、それぞれその端末装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データを収集する処理を、繰り返し実行する第２の情報収集手段；第１の情報収集手段が各製造処理部から収集した検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する不良基板認識手段；各工程における処理時間および工程間における基板の搬送時間、ならびに第１の情報収集手段が収集した各基板の処理状況データに基づき、前記不良基板認識手段により認識された基板毎に、次の工程の処理が開始されるタイミングを予測する予測手段；不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを前記予測手段により予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するデータ列生成手段；第２の情報収集手段が各端末装置から収集した稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、データ列の先頭部分の確認要求コマンドを送信するデータ送信手段；の各手段を具備する。
【００２３】
上記の構成によれば、第１、第２の各情報収集手段により、各製造処理部および端末装置から情報を収集するとともに、不良基板認識手段によりステップＡが、予測手段によりステップＢが、データ列生成手段によりステップＣが、データ送信手段によりステップＤが、それぞれ実行されることになる。なお、このサーバ装置は、１台のコンピュータに限らず、複数台のコンピュータによるネットワークシステムとして構成してもよい。
【発明の効果】
【００２４】
上記の目視確認処理の管理方法およびサーバ装置によれば、不良と判定された基板は、次の工程の処理が開始されると予測されるタイミングが早いものから順に目視確認の対象とされるので、目視確認による次の工程の処理の遅延を防止することが可能になる。また、目視確認の割り当ては、目視確認処理を実行可能な端末装置に対して行われるので、特定の係員に処理が集中することがなく、係員間の負荷のばらつきを小さくすることができる。よって、目視確認作業を効率良く進行させて、ラインが停滞するのを防止することができる。
【発明を実施するための最良の形態】
【００２５】
図１は、この発明が適用された基板生産システムの構成例を示す。
この基板生産システム１０は、複数本（図示例ではライン１，２の２本）の基板生産ラインにより、多数枚の基板の生産および検査を一連に実行するものである。各ラインには、クリームはんだの印刷工程（略号をＰとする。）、部品の実装工程（略号をＺとする。）、およびリフロー工程（略号をＳとする。）の３つの工程が含まれる。
【００２６】
いずれの工程にも、その工程の処理を自動で実行するための「製造処理部」が設けられる。印刷工程の製造処理部である印刷処理部１１は、はんだ印刷機１Ａと印刷後検査装置２Ａにより構成される。実装工程の製造処理部である実装処理部１２は、部品実装機１Ｂ（マウンタ）と実装後検査装置２Ｂとにより構成される。リフロー工程の製造処理部であるリフロー処理部１３は、リフロー炉１Ｃとリフロー後検査装置２Ｃとにより構成される。
【００２７】
以下、それぞれの工程の実質的な処理を担当するはんだ印刷機１Ａ、部品実装機１Ｂ、リフロー炉１Ｃを、「製造装置１」と総称し、印刷後検査装置２Ａ、実装後検査装置２Ｂ、リフロー後検査装置２Ｃを、「検査装置２」と総称する。各検査装置２は、カメラやコンピュータを有する自動外観検査装置であって、設置されている工程に応じた内容の検査を実行する。
【００２８】
各製造装置１および検査装置２は、それぞれライン外に設けられたサーバ装置３に通信回線を介して接続されている。さらに、サーバ装置３は、第２の通信回線を介して複数台の端末装置４に接続されている。各端末装置４は、パーソナルコンピュータにキーボード、マウス、モニタなどの周辺機器を接続した構成のものである。
【００２９】
上記の基板生産システム１０では、各ラインでＰ、Ｚ、Ｓの各工程を順に実行することにより、部品実装基板を完成させる。また、工程毎に検査装置２による自動検査を実行し、すべての工程の検査で「良品」と判定された基板のみを出荷する。ただし、自動検査では「見過ぎ」が生じる場合があるので、この実施例では、各工程で不良判定がなされても、その対象の基板をすぐには取り除かずに次の工程（最終のリフロー工程の場合には、ラインの終端位置をいう。以下も同じ。）に搬送し、不良と判定された被検査部位（不良判定部位）の画像を端末装置４に表示して、担当の係員による目視確認処理を行うようにしている。
【００３０】
サーバ装置３は、各検査装置２から検査に用いた画像の配信を受け付けて、内部のメモリに蓄積する。また、サーバ装置３は、各工程の製造処理部の稼動状態や検査結果を認識して、各端末装置４に目視確認の対象の被検査部位を割り当てるとともに、端末装置４からの確認結果を受け付けて、モニタに表示するなどの報知を行う。この報知された目視確認結果が「不良」である場合には、その不良判定がされた基板を取り除く作業が行われる。一方、目視確認結果が「見過ぎ」である場合には、基板は良品であると判断されて、つぎの工程の処理が実行される。
【００３１】
図２は、サーバ装置３の機能ブロック図である（ただし、製造装置１、検査装置２、端末装置４との関係を示すために、これらの装置を１個ずつ示す。)。この図に示すように、サーバ装置３には、工程マスタテーブル、基板状況テーブル、検査結果テーブルの３種類のテーブル（図２ではＴＢと略す。）を保存するためのデータベース３０１，３０２，３０３が設けられる。工程マスタテーブルは、製造処理部毎に設定されるもので、対応する製造処理部が１枚の基板を処理するのにかかる時間（製造装置１、検査装置２の各処理時間に装置１，２間における基板の搬送時間を合算した時間である。以下、この時間を「処理時間」という。）や、次の工程に１枚の基板を搬送するのにかかる時間（以下、「搬送時間」という。）が格納される。
【００３２】
基板状況テーブルおよび検査結果テーブルは、ラインに送り込まれた基板毎に設定される。図３は、これらのテーブルのデータ構成例を示す。なお、この図３では、複数のデータのいずれかを選択して格納される領域については、選択され得るデータを列挙し、そのうち、この例で選択されているデータを丸印で囲んで示す。
【００３３】
図３（１）に示す基板状況テーブルは、対応する基板が、現在、どの工程にどのような状態でいるかを示すものである。このテーブルには、基板を特定するための情報として、基板ＩＤおよびライン投入番号が格納されるほか、ライン番号、現処理工程、処理状況、処理開始時刻、処理終了時刻、処理開始予定時刻などの情報が格納される。
【００３４】
『基板ＩＤ』は、各基板に固有の識別コードである。『ライン投入番号』は、ラインへの基板の投入順に設定されるシリアル番号であって、基板ＩＤと同様に、基板毎に固有の情報である。ただし、目視確認により不良が確認されて、基板がラインから除去され、修正作業後にラインに再投入される場合には、『基板ＩＤ』は書き換えられないが、『ライン投入番号』は新たな番号に書き換えられる。『ライン投入番号』は、ラインの先頭の印刷処理部１１、または図示しないライン統括用の制御部により付与される。
【００３５】
『ライン番号』は、基板が投入されるラインの識別コードである。『現処理工程』とは、現在、基板を管轄している工程であって、各工程の略号であるＰ，Ｚ，Ｓ、および全ての工程を終了したことを示すデータ「Ｅｎｄ」のうちのいずれかが格納される。なお、各工程とも、自工程の入口（図示しない受付装置が配備されている地点）から次の工程の入口の手前までを管轄範囲とする。基板状況テーブルの『処理状況』は、この管轄範囲における基板への具体的な処理の内容を示すもので、基板受付部に待機している場合には「待ち」が、製造または検査が行われている場合には「処理中」が、次工程への搬送が行われている場合には「搬送中」が、それぞれ選択される。
【００３６】
『処理開始時刻』は、管轄の工程の製造装置１による処理が開始された時刻であり、『処理終了時刻』は、管轄の工程の検査装置２による検査が終了した時刻である。これらはいずれも現実の時刻なので、実際に処理が開始または終了するまで書き込まれない。
【００３７】
『処理開始予定時刻』は、サーバ装置３の予測処理により、製造処理部による処理が開始される時刻として割り出された時刻である。この予測処理は、処理が開始される前の待機状態の基板、および処理が終了して次の工程への搬送が開始された基板に対して行われる。すなわち、ある工程の検査を終了した基板について、次の工程が開始される時刻を予測することになる。
【００３８】
（２）−１の検査結果テーブルは、基板全体の総合的な検査結果を示すもので、ラインを流れる基板毎に作成され、検査の都度、書き換えられる（または検査毎に異なるテーブルが作成される場合もある。）。このテーブルには、基板ＩＤ、処理工程、検査結果（ＯＫまたはＮＧ）、目視結果（ＯＫ、ＮＧ、Ｎｕｌｌのいずれか）などが格納される。なお、目視結果の「Ｎｕｌｌ」は、目視確認作業がまだ行われていないことを示すものである。
【００３９】
（２）−２のＮＧデータテーブルは、不良判定された基板について、不良判定部位毎に作成されるもので、不良判定部位を特定するためのデータとして、基板ＩＤおよび被検査ＩＤが格納される。さらに、この部位の目視検査を担当した端末装置４のＩＤ、自動検査の結果（ＮＧのみ）、および目視結果（ＯＫ、ＮＧ、Ｎｕｌｌのいずれか）が格納される。なお、このＮＧデータテーブルも、検査結果テーブルとともに、検査結果テーブルデータベース３０３に格納される。
【００４０】
図２に戻って、上記した３種類のデータベース３０１，３０２，３０３に対するデータの格納処理は、情報収集処理部３０５により行われる。情報収集処理部３０５は、基板状況テーブルデータベース３０２や検査結果テーブルデータベース３０３に対しては、所定の時間毎に新しい情報の配信を受け付けてテーブルの内容を書き換える。一方、工程マスタテーブルデータベース３０１については、原則として、システムの立ち上げ時などに、各工程から情報を取り込んでテーブルに書き込むのみであり、その後は更新しない。
【００４１】
さらにサーバ装置３には、画像データベース３０４や、この画像データベース３０４に格納する画像を各検査装置２から受け付けるための画像入力部３１３が設けられる。画像データベース３０４には、各検査装置２の検査に使用された画像が部品単位のファイルとして格納されている。各画像には、基板および部品の識別コード（以下、それぞれを「基板ＩＤ」、「部品ＩＤ」という。）ならびに検査を実行した工程の略号（Ｐ，Ｚ，Ｓ）を含むファイル名が付されているので、これらの情報を特定することによって、検査に使用された画像を読み出すことができる。
【００４２】
上記のほか、サーバ装置３には、処理開始時刻予測部３０６、確認待ち行列生成部３０７、確認待ち行列記憶部３０８、割当処理部３０９、目視結果入力部３１０、行列更新部３１１、目視結果書込部３１２、アクセス受付部３１４、画像読出部３１５などが設けられる。これらは、いずれも、サーバ装置３の図示しないＣＰＵを含むハードウェアとプログラムとが協同することにより設定される機能である。
【００４３】
処理開始時刻予測部３０６は、工程マスタテーブルや基板状況テーブルを参照して、各工程の待機状態または搬送中の基板について、前記した処理開始予定時刻を求める処理を実行する。具体的な時刻算出方法については後記する。
【００４４】
確認待ち行列生成部３０７は、各基板の検査結果テーブルや、不良判定された基板のＮＧデータテーブルを用いて、各工程で不良と判定された基板や具体的な不良判定部位を認識し、その部位毎に、端末装置４に目視確認を要求するコマンド（以下、「確認要求コマンド」という。）を設定する。この確認要求コマンドには、目視確認の対象部位に対応する画像ファイルのファイル名が含まれている。
【００４５】
さらに確認待ち行列生成部３０７は、不良と判定された基板について、処理開始時刻予測部３０６から処理開始予定時刻を取り込み、その時刻が早い基板に対応するものから順に、確認要求コマンドを配列する。この配列により生成されたデータ列を、「確認待ち行列」という。生成された確認待ち行列は、確認待ち行列記憶部３０８に保存される。
【００４６】
割当処理部３０９は、各端末装置４との通信により、係員がおり、かつ目視確認処理が行われていない端末装置４を「目視確認の要求を受付可能な端末」と認識し、認識した端末装置４に、確認待ち行列の先頭の確認要求コマンドを割り当てる。そして、割り当てた確認要求コマンドを、そのコマンドを割り当てた端末装置４に送信することにより、対象の被検査部位を特定した目視確認処理を要求する。
【００４７】
端末装置４では、上記の確認要求コマンドを受け付けると、そのコマンド中の画像ファイル名を、リンク付きデータとしてモニタに表示する。係員がこのリンク付きデータをクリックすると、そのデータは、サーバ装置３のアクセス受付部３１４を介して画像読出部３１５に送られる。画像読出部３１５は、データの内容に基づき画像データベース３０４を検索して、対応する画像を読み出す。読み出された画像は、アクセス受付部３１４を介して、アクセスを行った端末装置４に返送される。
【００４８】
端末装置４では、送信された画像をモニタに表示する。係員は、この表示画面により不良判定部位の状態を目視確認し、判断の結果を示すデータ（ＯＫまたはＮＧ）を入力する。入力されたデータは、サーバ装置３の目視結果入力部３１０に送信された後、行列更新部３１１や目視結果書込部３１２に渡される。
【００４９】
目視結果書込部３１２は、供給された目視結果データを、該当する基板の検査結果テーブルやＮＧデータテーブルを書き換える。すなわち、各テーブル中の目視結果データを、ＮｕｌｌからＯＫまたはＮＧに書き換えることになる。行列更新部３１１は、割当処理部３０９による確認要求コマンドの割り当てに応じて、確認待ち行列の先頭のコマンドを消去する。また、目視結果入力部３１０から供給された目視結果データが「ＮＧ」であったときは、行列更新部３１１は、その目視結果に対応する基板について、確認待ち行列に確認要求コマンドが残っていないかどうかを確認し、残っていれば、消去する。
【００５０】
図４は、確認要求コマンドの構成およびコマンドの割り当て処理の方法を、模式的に示す。この例では、個々の不良判定部位に対応する確認要求コマンドを丸印に置き換えて、確認待ち行列の構成を表している。各コマンド内の数字は、各基板の処理開始予定時刻を早いものから順に並べたときの順序を表す。また、この図では、４台の端末装置４を、それぞれ「端末Ａ」「端末Ｂ」「端末Ｃ」「端末Ｄ」として示す。
【００５１】
図４の確認待ち行列には、４枚の基板につき生成された確認要求コマンドが含まれている。４枚のうち処理開始予定時刻が最も早い基板（「１」が付されたコマンドに対応するもの）には、７個の不良判定部位があり、そのうちの２個が、端末Ｂ，Ｃで目視確認されている。この例では、残り２台の端末装置４のうち、端末Ａが処理が可能な状態にあるので、この端末Ａに確認待ち行列の先頭の確認要求コマンドが送信される。さらに、処理中の端末Ｂ，Ｃの処理が終了したり、端末Ｄに係員が戻ってきた場合には、これらの端末装置４に、確認待ち行列のつぎの確認要求コマンドが送信されることになる。
【００５２】
図５は、目視確認処理で不良判定が行われた場合の確認待ち行列の更新例を示す。この図の上段は、図４に示した割り付け処理が行われて、端末Ａに送信した先頭の確認要求コマンドが消去された状態を示す。この状態下で端末Ａから「ＮＧ」の目視結果データが送信されたものとすると、図５の下段に示すように、行列更新部３１１によって、確認待ち行列に残っていた１枚目の基板の確認要求コマンドがすべて消去され、２番目の基板の確認要求コマンドが繰り上げられる。これにより、明らかな不良によりラインから回収される基板を目視の対象から外し、目視確認に待機している基板を優先的に処理することができるので、目視確認の効率を向上させることができる。
【００５３】
なお、端末装置４側の処理に余裕がある場合には、先頭から削除したコマンドを確認待ち行列の最後尾に配置して、目視確認を行うようにしてもよい。
【００５４】
図６は、ライン１，２で不良判定された基板に対し、従来の方法による目視確認処理を行う場合の検査結果と処理の流れとの関係を示す。この例では、ライン１，２とも、実装工程（Ｚ）からリフロー工程（Ｓ）に向けて、４枚の基板が流されるものとして、Ｚ，Ｓの工程および基板毎に、自動検査により不良と判定された部位の数（不良判定数）と、目視により不良と判定された部位の数（実不良数）とを対比させたテーブルと、基板毎のタイムチャートとを、左右に対応づけて示している。各テーブルの『ＩＤ』は、前出の基板ＩＤである。いずれのラインでも、この基板ＩＤが若い基板から順に搬送して、この図に示していない印刷工程（Ｐ）、およびＺ，Ｓの各工程を順次実行する。
【００５５】
なお、図６および次の図７では、同一基板に対する各工程間の処理の切り替わりを、矢印により示している。またタイムチャート中の「処理」には、製造装置１における処理と検査の双方が含まれる。また太枠部分は、処理の終了した基板を次工程またはラインの終端に搬送している期間にあたり、目の細かい網点パターンで示す期間は、目視確認処理の期間を示す。
【００５６】
図６の従来例では、各ラインの各工程毎に、それぞれ１台の専用の端末装置４が設置され、各工程で不良判定された基板の目視確認処理を、それぞれその工程を担当する端末装置４でのみ確認する。このような処理を行う場合、１枚の基板に多数の不良判定部位があると、その基板に対する確認作業が長引き、その結果、処理待ちの時間が長くなって、後続の基板の処理に影響を及ぼす場合がある。
【００５７】
たとえば、図６の例では、ライン１の実装工程（Ｚ）において、最初の基板（ＩＤ：１００１）に１０個の不良判定部位があり、次のリフロー工程（Ｓ）への搬送が終了しても目視確認が終了しなかったため、この基板に対するリフロー工程の開始が遅れている。また、１番目の基板の目視確認処理が長引いたことにより、つぎの基板（ＩＤ：１００２）に対する目視確認の開始が遅れ、その結果、この基板に対するリフロー工程の開始も遅れている。さらに、この２枚目の基板の処理の遅れによって、３、４枚目の基板（ＩＤ：１００３，１００４）に対するリフロー工程に大幅な遅れが生じている。
【００５８】
またライン２では、実装工程（Ｚ）において、２番目の基板（ＩＤ：２００２）に多数の不良判定部位があって目視確認が長引いた上に、実際に不良の部位があることが確認されて、この基板を取り除く作業が行われている。この間に、後続の３枚目、４枚目の基板（ＩＤ：２００３、２００４）がリフロー工程に到着しているが、３枚目の基板に対する目視確認処理の開始が遅れた上に、この３枚目の基板にも多数の不良判定部位があったため、目視確認処理の時間が長くなっている。この結果、３，４枚目の基板に対するリフロー工程は、大幅に遅れて開始されている。
【００５９】
図７は、図６の例と同様の検査結果に対し、図３に示した割り当て処理を実行する場合の処理の流れを示す。この例では、すべてのライン、全ての工程で生じた不良判定部位をとりまとめ、目視確認を急ぐものから順に、処理が可能な端末装置４に割り当てる。この割り当ては、個々の不良判定部位毎に行われるので、ライン１の１番目の基板のように、不良判定部位が多い基板があっても、複数の端末装置４で分担して確認作業を行うことができる。この結果、いずれの基板でも、従来例に比べて目視確認期間が大幅に短縮されるので、図７の例のように、搬送時間内に目視確認を終了することが可能になる。
【００６０】
また、ライン２では、２番目の基板に実際に不良箇所があって、ラインから基板を取り除く必要があるが、この例では複数の端末装置４で目視確認作業を分担でき、しかも不良が確認された段階で処理を打ち切るので、図６の例より格段に早く目視確認処理を終了することができる。この結果、後続の基板についても、搬送時間内に目視確認を終了することができるので、リフロー工程に到着後すぐに処理を開始できる状態となっている。
【００６１】
以下、図８〜１１を用いて、サーバ装置３の具体的なアルゴリズムを説明する。
まず、図８および図９は、確認待ち行列の生成処理（処理開始予定時刻の算出を含む。）の流れを示す。この処理では、各ラインの各工程について、ライン数の若い順、および上流から下流に向かう順に、ＳＴ１０１〜１１８のループを実行する。
【００６２】
このループでは、まず、ＳＴ１０２において、着目中の工程について、工程マスタテーブルから、処理時間Ｖおよび搬送時間Ｗを読み出す。つぎにＳＴ１０３において、ライン番号および工程の略号に基づき、基板状況テーブルデータベース３０２から着目中の工程の管轄下にある基板の基板状況テーブルを読み出し、図示しない作業用メモリに保存する。
【００６３】
つぎに読み出した各テーブルの処理状況データをチェックする。ここで、処理状況データが「搬送中」のテーブルがあれば、ＳＴ１０４が「ＹＥＳ」となり、その「搬送中」の基板について、以下のＳＴ１０５およびＳＴ１０６を実行する。
【００６４】
「搬送中」の基板は、製造装置１における処理および検査が終了した基板であるから、その基板状況テーブルには、処理終了時刻が書き込まれているはずである。ＳＴ１０５では、この処理終了時刻を読み出し、その時刻に搬送時間Ｗを加えた時刻Ｔを算出する。つぎのＳＴ１０６では、Ｔの値を、「搬送中」の基板の処理開始予定時刻として、基板状況テーブルに保存する。
【００６５】
つぎに、ＳＴ１０３で読み出された基板状況テーブルの中に、処理状況データが「待機中」のものがある場合には、ＳＴ１０７が「ＹＥＳ」となり、ＳＴ１０８〜１１７の処理を実行する。
【００６６】
ＳＴ１０８では、ＳＴ１０３で読み出された基板状況テーブルの中に、処理状況データが「処理中」のテーブルがあるかどうかをチェックする。このテーブルが存在する場合、すなわち着目中の工程で所定の基板を処理している場合には、ＳＴ１０８が「ＹＥＳ」となってＳＴ１０９に進み、その処理中の基板の処理開始時刻に、ＳＴ１０２で読み出した処理時間Ｖを加えた時刻Ｔ０を求める。一方、処理中の基板がない場合には、ＳＴ１０８が「ＮＯ」となってＳＴ１１０に進み、現在時刻をＴ０とする。
【００６７】
上記の時刻Ｔ０は、待機中の先頭の基板に対する処理が開始される時刻に相当すると考えられる。以下では、待機中の基板毎に、ＳＴ１１１〜１１５のループが実行される。
【００６８】
このループのＳＴ１１２では、まず他の待機中の基板の基板状況テーブルを用いて、ライン投入番号が着目中の基板より若い基板（すなわち、着目中の基板より先に処理される基板である。）の数Ｎを求める。ＳＴ１１３では、先の時刻Ｔ０に（Ｎ×Ｖ）時間を加えた時刻を求め、これを時刻Ｔとする。ＳＴ１１４では、このＴを着目中の基板の処理開始予定時刻として、その基板の基板状況テーブルに保存する。
【００６９】
このようにして、待機中の基板毎に処理開始予定時刻を求めると、ＳＴ１１６では、これらのうち最も遅い時刻と現在時刻との差を求め、これを待機中基板の最大待ち時間とする。ＳＴ１１７では、着目中の工程の１つ上流の工程の管轄にある搬送中基板の処理開始予定時刻を、その時刻にＳＴ１１６で求めた最大待ち時間を加えた時刻と比較し、より遅い方の時刻を処理開始予定時刻とする。ただし、最初の工程である印刷工程については、ＳＴ１１６，１１７はスキップされる。
【００７０】
このように、待機状態にある基板については、その基板を管轄する工程の処理時間と先行の基板の数とに応じて、待機中の処理の処理開始予定時刻が算出される。また、処理を終了してつぎの工程に搬送されている基板については、その基板がつぎの工程に到着する時刻と先行の基板の数とに基づき、つぎの工程の処理の処理開始予定時刻が算出される。
【００７１】
すべてのライン、工程の組み合わせについて、ＳＴ１０１〜１１８のループが実行されると、ＳＴ１１９では、処理状況データが「搬送中」または「待機中」の基板の検査結果テーブルを参照して、不良と判定された基板の基板ＩＤを抽出する。ＳＴ１２０では、ＳＴ１１９で抽出された基板ＩＤ毎に、そのＩＤが格納された基板状況テーブルから処理開始予定時刻を読み出す。さらにＳＴ１２１では、各基板ＩＤを、処理開始予定時刻の早いものから順にソートする。このソート処理により、不良と判定された基板は、その判定がされてから次の工程の処理が開始されるまでの時間が短いものから順に、並べられることになる。
【００７２】
ＳＴ１２２では、ソートされた各基板ＩＤにリンクするＮＧデータテーブルから、それぞれ基板ＩＤおよび被検査部位ＩＤを読み出し、この２種類のＩＤを用いて確認要求コマンドを作成する。すなわち、不良判定部位毎に、確認要求コマンドが作成されることになる。ＳＴ１２３では、作成されたコマンドデータを、基板ＩＤのソート後の順序に沿って配列する。さらに、ＳＴ１２４では、ＳＴ１２３の処理により生成されたデータ列を、確認待ち行列として、確認待ち行列記憶部３０８に保存する。
【００７３】
上記の確認待ち行列の生成処理は、データベース３０２，３０３が更新される毎に実行される。この場合に、確認待ち行列記憶部３０８に一段階前の確認待ち行列が残っていても、ＳＴ１２４では、これを消去し、新たな確認待ち行列を保存する。しかし、処理開始予定時刻については、一段階前の算出値を保持しておき、各工程の管轄に新たに入った基板のみを対象に、処理開始予定時刻を算出してもよい。ただし、端末装置４の目視確認処理で「不良」と判定されてラインから取り除かれた基板の後続基板について、確認要求コマンドが確認待ち行列に残っている場合には、データベース３０３内の先行基板の検査結果テーブルに「ＮＧ」が書き込まれたときに、後続基板の処理開始予定時刻を更新しておくのが望ましい。
【００７４】
図１０は、確認待ち行列の各確認要求コマンドを端末装置４に割り当てる処理の流れを示す。
この実施例の端末装置４は、自装置の稼働状態や入力データに基づき、「処理ＯＫ」「処理中」「離席中」のいずれかを示す状況データを定期的にサーバ装置３に送信している。図１０の最初のステップであるＳＴ２０１では、この状況データの送信を受け付け、現在、処理が可能な端末装置４があるかどうかを確認する。
【００７５】
ここで処理が可能な端末装置４があり、また確認待ち行列が保存されている場合には、ＳＴ２０２，２０３が「ＹＥＳ」となってＳＴ２０４に進む。ＳＴ２０４では、確認待ち行列の先頭のコマンドを処理が可能な端末装置４に送信する。ＳＴ２０５では、この送信したコマンドを、確認待ち行列から削除する。
【００７６】
ＳＴ２０１〜２０５の処理は、サーバ装置３に処理終了指令が入力されるまで繰り返し実行される。処理が可能な端末装置４がない場合または確認待ち行列が保存されていない場合も、処理終了指令が入力されない限り、ＳＴ２０１に戻って、同様の処理を繰り返す。処理終了指令が入力されると、ＳＴ２０６が「ＹＥＳ」となり、一連の処理を終了する。
【００７７】
図１１は、端末装置４からの目視確認結果の送信を受け付けて、確認待ち行列や検査結果テーブルを更新する処理の流れを示す。なお、この処理でも、処理終了指令が入力されるまで、繰り返し実行される。
【００７８】
端末装置４から送信される目視確認結果には、判断結果を示すＯＫまたはＮＧのデータのほか、対応する確認要求コマンドに含まれていた基板ＩＤ、被検査部位ＩＤが含まれている。サーバ装置３では、いずれかの端末装置４からのデータ送信を受け付けると、ＳＴ３０１からＳＴ３０２に進み、送信された各種データを入力する。さらに、ＳＴ３０３では、受け付けたデータに含まれている基板ＩＤおよび被検査部位ＩＤに基づき、受信データに対応するＮＧデータテーブルを特定し、そのテーブルに受信した目視結果データを書き込む。
【００７９】
さらに書き込んだ目視結果データが「ＮＧ」であれば、ＳＴ３０４が「ＹＥＳ」となってＳＴ３０５に進み、確認待ち行列から同じ基板ＩＤに対応する確認要求コマンドを削除する。さらに、ＳＴ３０６では、上記の基板ＩＤに対応する検査結果テーブルを特定し、その目視結果に「ＮＧ」を書き込む。
【００８０】
一方、ＳＴ３０３で書き込まれた目視結果データが「ＯＫ」であれば、ＳＴ３０４からＳＴ３０７に進み、同じ基板ＩＤに対応するコマンドが確認待ち行列中に残っているかどうかを、さらにつぎのＳＴ３０８で当該コマンドを処理中の端末装置４があるかどうかを、それぞれチェックする。ここで該当するコマンドが行列中に残っておらず、他の端末装置４で処理されていることもなければ、今回取得した目視結果データが、対応する基板にかかる最終の目視確認処理に対応することになる。よって、この場合には、ＳＴ３０７，３０８の判定が共に「ＮＯ」となってＳＴ３０９に進み、該当する基板の検査結果テーブルの目視結果に「ＯＫ」を書き込む。一方、ＳＴ３０７およびＳＴ３０８のいずれかが「ＹＥＳ」となった場合には、ＳＴ３０９の処理はスキップされる。なお、図示していないが、ＳＴ３０６やＳＴ３０９では、目視結果データに対応するＮＧデータテーブルについても、検査結果テーブルと同様のデータ更新を行う。
【００８１】
上記のように、この実施例では、各検査装置２で不良と判定された基板について、その検査後の工程の処理が開始される時刻が早いものから順に目視確認処理を行うとともに、１枚の基板に複数の不良判定部位がある場合には、これらの部位に対する目視確認処理を複数の端末装置４で分担できるようにしたから、目視確認処理に要する時間を従来より大幅に短縮でき、また、係員の負荷がばらつくのを防止することができる。よって、ラインにおける基板の停滞を防止することができ、基板の生産効率を向上することが可能になる。
【００８２】
ただし、各工程の製造処理部では、従前と同様に、前工程の検査で不良と判定された基板については、目視確認処理が終了し、不良判定部位がすべて「ＯＫ」でなければ処理を開始しない。したがって、仮に、端末装置４側の処理が混雑するなどして、不良判定された基板が次工程に到着するまでに目視確認を終了できなかった場合でも、目視確認の終了前に処理が開始されることはなく、基板の品質を確保することができる。
【００８３】
なお、上記実施例では、最終工程のリフロー工程についても、ライン終端を「次の工程」とみなして処理開始予定時刻を算出しているが、リフロー工程後の基板の確認は、ライン終端から基板を回収した後で行っても支障はない。したがって、印刷工程および実装工程で不良判定された基板のみを対象に、処理開始予定時刻を算出して確認待ち行列を作成した後に、リフロー工程で不良判定された基板に対応する確認要求コマンドを、確認待ち行列の後尾に付加してもよい。ただし、リフロー炉の後段に、プローブを用いた導通検査の工程が設けられている場合には、導通検査に要する時間や、リフロー工程から導通検査の工程への搬送時間などに応じて、リフロー工程における「次の工程の処理開始予定時刻」を求め、その時刻を反映した確認待ち行列を生成するようにしてもよい。
【００８４】
さらに上記したコマンド割り付け処理には、以下のような処理を加えることができる。
（１）所定の条件に応じて、複数の確認要求コマンドを１台の端末装置４に送信できるようにする。たとえば、同じ基板に対応する不良判定部位の数をｎ、一人の係員が１つの部位の目視確認に要する平均時間をｔとした場合、ｎ×ｔの値が上記基板の処理開始予定時刻までの待ち時間より小さければ、そのｎ個の不良判定部位に対応する確認要求コマンドを１台の端末装置４に送信する。
【００８５】
（２）確認待ち行列から削除したコマンドについても、別途、処理対象とする。すなわち、目視確認処理で実際に不良があると判断された基板について、確認待ち行列から削除した確認要求コマンドを、別の確認待ち行列として配列し、この行列のコマンドを端末装置４側の処理に余裕があるときに処理させる。実際に不良があると判断された基板はラインから回収された後、不良部位が修正されてラインに再投入されるが、この場合、前の検査で不良と判定された「見過ぎ」の部位について、再度、不良判定がなされる可能性がある。しかし、上記の方法により、修正後の再投入の前に未確認の不良判定部位の目視確認を完了し、その結果をＮＧデータテーブルに書き込んでおけば、同じ部位が再び不良と判定されても、そのＮＧデータテーブルを参照することにより、「見過ぎ」判定であると判断して、目視確認の対象から外すことができる。
【００８６】
なお、上記の処理は、必ずしも、確認待ち行列から削除したすべてのコマンドについて行う必要はない。たとえば、目視確認処理により多数の部位が「不良」と判断されたり、修正が困難な部位が「不良」と判断された場合には、修正を行わずに基板を廃棄することがある。このように、修正対象の基板が選択される場合には、「不良」と判断された部位の数や、不良と判断された部位の被検査部位ＩＤなどに基づき、修正作業が選択される基板に対応する確認要求コマンドのみを抽出して、上記（１）の処理の対象とするのが望ましい。
【００８７】
（３）不良の発生率に基づいて確認要求コマンドの配列順序を決定する。たとえば、あらかじめ、過去の同一種類の基板につき作成されたＮＧデータテーブルを用いて、被検査部位毎に、自動検査および目視確認結果がともに「ＮＧ」となった回数を計数し、その回数の全検査数に対する比率（実際の不良の発生率に相当する。）を算出する。確認待ち行列の生成処理では、同一基板または処理開始予定時刻が同じ基板に対応する不良判定部位の確認要求コマンドを、上記の不良の発生率が高い順に配列する。このようにすれば、実際に不良である可能性の高いものから目視確認を行うことができるから、不良が早期に発見される可能性が高められる。また、確認要求コマンドの数が少なかったり、処理開始予定時刻までに余裕があるような場合には、処理開始予定時刻を考慮せずに、不良の発生率のみに基づき各コマンドを配列してもよい。
【００８８】
（４）各係員が担当する対象部位を決めておき、目視確認の対象部位を担当者に優先的に割り当てる。不良判定部位の目視確認処理では、処理の都度、確認対象部位が異なるよりも、同種の部位を続けて確認した方が、効率が良く、判断の精度も高くなるとと思われる。そこで、あらかじめ、各係員の担当する部位を定めておき、同一基板または処理開始予定時刻の差が所定値以内の基板に対応する複数の不良判定部位を、それぞれの担当者の端末に割り付ける。ただし、特定の係員に負荷が偏るのを防止するために、一人の係員に割り当てる数に制限を設けたり、担当の係員への割当数が制限値を超える場合には、他の係員の端末装置４にも割り当てるなど、柔軟性をもたせた処理にする必要がある。
【００８９】
（５）目視担当の係員の習熟度や不良発生部位の種類を考慮して割当処理を行う。不良発生部位によっては、十分な経験を積んだ係員でなければ、正確な目視確認を行えない場合があるからである。
【００９０】
たとえば、あらかじめ、目視の難しい部位の被検査部位ＩＤを集めたリストをサーバ装置３に登録しておき、不良発生部位のＩＤがこのリストに入っている場合には、対応する確認要求コマンドの送信先を、習熟度の高い係員の端末装置４に限定する。この場合に、この係員が離席または処理中でコマンドを送信できず、他の端末装置４が処理可能な状態であれば、その空き端末には後のコマンドを送信して処理を進めるようにしてもよい。
【図面の簡単な説明】
【００９１】
【図１】基板生産ラインの構成例を示すブロック図である。
【図２】サーバ装置の機能ブロック図である。
【図３】基板状況テーブル、検査結果テーブル、ＮＧデータテーブルの構成例を示す説明図である。
【図４】確認待ち行列の構成および端末装置に対する割当処理の方法を示す説明図である。
【図５】目視確認処理でＮＧ判定がされた場合の処理例を示す説明図である。
【図６】従来の方法で目視確認処理を行う場合の検査結果と処理の流れとの関係を示す説明図である。
【図７】図４の方法により目視確認処理の割当を行った場合の検査結果と処理の流れとの関係を示す説明図である。
【図８】確認待ち行列の生成処理に関する処理の手順を示すフローチャートである。
【図９】図８の続きのフローチャートである。
【図１０】割当処理の手順を示すフローチャートである。
【図１１】目視確認結果の受信に伴うデータ更新処理の手順を示すフローチャートである。
【符号の説明】
【００９２】
１ 製造装置
２ 検査装置
３ サーバ装置
４ 端末装置
１０ 基板生産システム
１１ 印刷処理部
１２ 実装処理部
１３ リフロー処理部
３０５ 情報収集処理部
３０６ 処理開始時刻予測部
３０７ 確認待ち行列生成部
３０９ 割当処理部
３１０ 目視結果入力部
３１１ 行列更新部
【技術分野】
【０００１】
この発明は、複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各自動外観検査装置（以下、単に「検査装置」という場合もある。）による検査結果を確認する技術に関する。特にこの発明は、検査装置で不良と判定された被検査部位の画像を、本当に不良であるかどうか目視により判断するために、複数人の係員に行わせる目視確認処理を管理する方法、およびこの方法を実施するサーバ装置に関する。
【背景技術】
【０００２】
部品実装基板の生産ラインには、一般に、クリームはんだの印刷工程、部品の実装工程、およびリフロー工程の３種類の工程が含まれる。また工程毎に自動外観検査装置を設け、処理後の基板を検査してから後続の工程に流すようにしたラインについて、検査に使用された画像を検査結果とともにモニタに表示して、係員による確認作業を行えるようにした基板検査システムも提案されている（特許文献１参照）。
【０００３】
ただし自動検査を行う場合には、判定基準値の設定によって、実際は不良でないのに不良と判定されることがある（以下、この誤判定を「見過ぎ」と呼ぶ。）。このため、従来の基板生産ラインには、各自動検査装置に専用の端末装置を接続し、この端末装置に不良と判定された被検査部位の画像を送信して、係員による目視確認を行うものがある（特許文献２の段落０００３，図７参照）。
【０００４】
【特許文献１】特開２００５−３０３２６９号公報
【特許文献２】特許第３７２４８５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
不良判定部位の目視確認を行う場合には、最終工程以外の工程で不良判定がなされても、「見過ぎ」と判断されれば、不良と判定された基板を取り除かずに次の工程に搬送するので、そのまま次の工程の処理を進めることができる。しかし、この方法では、目視確認が終了するまで次の工程を実行せずに待機する必要があるため、不良判定部位が増えたり、確認作業の時間が長くなったりすると、処理待ちの基板が増えてラインが停滞するおそれがある。
【０００６】
また、従来の確認作業では、ラインや工程毎に目視確認の担当者が割り振られているので、あるラインで多数の不良判定部位が発生した場合、他のラインの担当者が手すきの状態であっても、不良判定部位が発生したラインの担当者のみで対応しなければならず、その結果、その担当のラインのみが停滞することがあった。
【０００７】
この発明は上記の問題に着目してなされたもので、不良判定部位の目視確認のためにラインが停滞したり、目視確認の担当者の負荷にばらつきが生じるのを解消し、基板生産ラインを効率良く稼動させることを、課題とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するための基板生産ラインにおける目視確認処理の管理方法では、各工程の製造処理部、およびライン外に配備される複数の端末装置を、それぞれ共通のサーバ装置に接続し、各製造処理部は、管轄する基板の処理状況データおよび検査結果データをサーバ装置に送信する処理を、各端末装置は、自装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データをサーバ装置に送信する処理を、それぞれ繰り返し実行し、サーバ装置において、下記のステップＡ、Ｂ，Ｃ，Ｄを実行するようにしている。
【０００９】
ステップＡでは、各製造処理部から送信された検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する。ステップＢでは、各工程における処理時間および工程間における基板の搬送時間、ならびに各製造処理部から送信された各基板の処理状況データに基づき、ステップＡで認識された基板毎に、次の工程の処理が開始されるタイミングを予測する。なお、この予測処理は、たとえば「次の工程が開始される時刻」または「次の処理が開始されるまでの待ち時間」を算出する処理として、実行される。
【００１０】
ステップＣでは、不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドをステップＢで予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成する。
【００１１】
ステップＤでは、各端末装置から送信された稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、ステップＣで生成したデータ列の先頭部分の確認要求コマンドを送信する。なお、「先頭部分の確認要求コマンド」は１つに限らず、複数のコマンドをまとめて送信してもよい。
【００１２】
上記の方法において、製造処理部や端末装置からサーバ装置へのデータ送信は、たとえば、一定の時間が経過する毎に実行しても良い（すなわち、定期的なデータ送信）が、これに限らず、新たなデータが発生する都度、行ってもよい（すなわち、不定期のデータ送信）。また、サーバ装置からのデータ送信要求に応じて、その時点で保持するデータを送信するようにしてもよい。
【００１３】
サーバ装置は、１台のコンピュータにより構成することができるが、これに限らず、複数台のコンピュータによるネットワークシステムとして構成してもよい。
【００１４】
上記のステップＡでは、最終工程以外の工程の製造処理部で不良と判定された基板を認識すれば良いが、これに限らず、全工程での不良判定基板を認識してもよい。ただし、この場合、最終工程で不良判定された基板については、ステップＢ，Ｃの対象とせず、その他の工程で不良と判定された基板に対する確認要求コマンドの送信が終了してから、確認要求コマンドの設定や送信を行うようにしてもよい。
【００１５】
各製造処理部からの処理状況データは、管轄する基板およびその基板に対する処理状況を表すものである。たとえば、管轄に入った基板の識別データと、その基板の現在の処理状況を示すデータ（待機中、処理中、処理済みなど）とを組み合わせたものとなる。
【００１６】
検査結果データは、検査が行われた基板およびその検査結果を表すものである。たとえば、検査が行われた基板の識別データと良否を示すデータ（ＯＫ／ＮＧ）とを組み合わせたものとなる。さらに個々の被検査部位のうち、少なくとも不良と判定された部位について、その部位の識別データや不良の内容を示すデータが検査結果データに含まれるのが望ましい。
【００１７】
確認要求コマンドは、どの基板のどの部位の画像を目視確認の対象とするかを示すものであるのが望ましい。たとえば、確認対象の不良判定部位を特定するデータ（たとえば、基板および不良判定部位の識別データの組み合わせ）、もしくはこの部位の画像を呼び出すためのデータ（たとえば、画像格納場所のアドレスや画像ファイル名など）を含むデータを、確認要求コマンドとする。
【００１８】
上記の方法によれば、不良と判定された基板を、次の工程の処理が開始されるタイミングが早い順に、目視確認処理を割り当てることができる。すなわち、確認処理を急ぐ必要がある基板から順番に、処理が可能な端末装置による確認作業を行うことが可能になるから、係員の負荷がばらつくのを防止して、効率良く、目視確認作業を進めることができる。
【００１９】
上記方法の好ましい態様では、ステップＢにおいて、最終の工程を除くいずれかの工程の検査装置で不良と判定されて次の工程に搬送される基板があるとき、次の工程の製造処理部から送信された処理状況データに基づき、当該次の工程が管轄する先行の基板の処理に要する時間を求め、次の工程に搬送される基板について、その搬送に要する時間から当該基板が次の工程の管轄に入る時刻を割り出し、その時刻から先行の基板の処理に要する時間が経過した時点の時刻を、次の工程の処理が開始される時刻として設定する。よって、複数のラインまたは工程において、同じ時期に不良判定が行われた場合でも、次の工程での処理待ち時間が少ないものから優先的に目視確認が行われるので、目視確認作業のために次工程の処理開始が遅くなるのを防止することができる。
【００２０】
さらに好ましい態様では、サーバ装置は、確認要求コマンドを送信した端末装置から、そのコマンドに対する目視確認結果を受け付けるステップＥと、このステップＥで受け付けた目視確認結果が不良である旨を示すとき、前記データ列から同一の基板に対応する確認要求データを削除するステップＦとを、さらに実行する。
【００２１】
上記の態様は、目視確認処理で「不良」と判断された基板がラインから取り除かれる場合に有用である。１枚の基板に複数の不良判定部位がある場合には、これらの部位毎に確認要求コマンドが設定されるが、これら不良判定部位のうちの１つが目視により「不良」と判断されると、残りの不良判定部位に対応する確認要求コマンドはすべてデータ列から削除される。よって、他の不良判定部位の確認要求データが繰り上げられ、目視確認作業の開始タイミングを早めることが可能になる。
【００２２】
上記の方法を実行する管理用のサーバ装置は、各ラインの各工程の製造処理部から、それぞれその処理部が管轄する基板の処理状況データおよび検査結果データを収集する処理を、繰り返し実行する第１の情報収集手段；各端末装置から、それぞれその端末装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データを収集する処理を、繰り返し実行する第２の情報収集手段；第１の情報収集手段が各製造処理部から収集した検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する不良基板認識手段；各工程における処理時間および工程間における基板の搬送時間、ならびに第１の情報収集手段が収集した各基板の処理状況データに基づき、前記不良基板認識手段により認識された基板毎に、次の工程の処理が開始されるタイミングを予測する予測手段；不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを前記予測手段により予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するデータ列生成手段；第２の情報収集手段が各端末装置から収集した稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、データ列の先頭部分の確認要求コマンドを送信するデータ送信手段；の各手段を具備する。
【００２３】
上記の構成によれば、第１、第２の各情報収集手段により、各製造処理部および端末装置から情報を収集するとともに、不良基板認識手段によりステップＡが、予測手段によりステップＢが、データ列生成手段によりステップＣが、データ送信手段によりステップＤが、それぞれ実行されることになる。なお、このサーバ装置は、１台のコンピュータに限らず、複数台のコンピュータによるネットワークシステムとして構成してもよい。
【発明の効果】
【００２４】
上記の目視確認処理の管理方法およびサーバ装置によれば、不良と判定された基板は、次の工程の処理が開始されると予測されるタイミングが早いものから順に目視確認の対象とされるので、目視確認による次の工程の処理の遅延を防止することが可能になる。また、目視確認の割り当ては、目視確認処理を実行可能な端末装置に対して行われるので、特定の係員に処理が集中することがなく、係員間の負荷のばらつきを小さくすることができる。よって、目視確認作業を効率良く進行させて、ラインが停滞するのを防止することができる。
【発明を実施するための最良の形態】
【００２５】
図１は、この発明が適用された基板生産システムの構成例を示す。
この基板生産システム１０は、複数本（図示例ではライン１，２の２本）の基板生産ラインにより、多数枚の基板の生産および検査を一連に実行するものである。各ラインには、クリームはんだの印刷工程（略号をＰとする。）、部品の実装工程（略号をＺとする。）、およびリフロー工程（略号をＳとする。）の３つの工程が含まれる。
【００２６】
いずれの工程にも、その工程の処理を自動で実行するための「製造処理部」が設けられる。印刷工程の製造処理部である印刷処理部１１は、はんだ印刷機１Ａと印刷後検査装置２Ａにより構成される。実装工程の製造処理部である実装処理部１２は、部品実装機１Ｂ（マウンタ）と実装後検査装置２Ｂとにより構成される。リフロー工程の製造処理部であるリフロー処理部１３は、リフロー炉１Ｃとリフロー後検査装置２Ｃとにより構成される。
【００２７】
以下、それぞれの工程の実質的な処理を担当するはんだ印刷機１Ａ、部品実装機１Ｂ、リフロー炉１Ｃを、「製造装置１」と総称し、印刷後検査装置２Ａ、実装後検査装置２Ｂ、リフロー後検査装置２Ｃを、「検査装置２」と総称する。各検査装置２は、カメラやコンピュータを有する自動外観検査装置であって、設置されている工程に応じた内容の検査を実行する。
【００２８】
各製造装置１および検査装置２は、それぞれライン外に設けられたサーバ装置３に通信回線を介して接続されている。さらに、サーバ装置３は、第２の通信回線を介して複数台の端末装置４に接続されている。各端末装置４は、パーソナルコンピュータにキーボード、マウス、モニタなどの周辺機器を接続した構成のものである。
【００２９】
上記の基板生産システム１０では、各ラインでＰ、Ｚ、Ｓの各工程を順に実行することにより、部品実装基板を完成させる。また、工程毎に検査装置２による自動検査を実行し、すべての工程の検査で「良品」と判定された基板のみを出荷する。ただし、自動検査では「見過ぎ」が生じる場合があるので、この実施例では、各工程で不良判定がなされても、その対象の基板をすぐには取り除かずに次の工程（最終のリフロー工程の場合には、ラインの終端位置をいう。以下も同じ。）に搬送し、不良と判定された被検査部位（不良判定部位）の画像を端末装置４に表示して、担当の係員による目視確認処理を行うようにしている。
【００３０】
サーバ装置３は、各検査装置２から検査に用いた画像の配信を受け付けて、内部のメモリに蓄積する。また、サーバ装置３は、各工程の製造処理部の稼動状態や検査結果を認識して、各端末装置４に目視確認の対象の被検査部位を割り当てるとともに、端末装置４からの確認結果を受け付けて、モニタに表示するなどの報知を行う。この報知された目視確認結果が「不良」である場合には、その不良判定がされた基板を取り除く作業が行われる。一方、目視確認結果が「見過ぎ」である場合には、基板は良品であると判断されて、つぎの工程の処理が実行される。
【００３１】
図２は、サーバ装置３の機能ブロック図である（ただし、製造装置１、検査装置２、端末装置４との関係を示すために、これらの装置を１個ずつ示す。)。この図に示すように、サーバ装置３には、工程マスタテーブル、基板状況テーブル、検査結果テーブルの３種類のテーブル（図２ではＴＢと略す。）を保存するためのデータベース３０１，３０２，３０３が設けられる。工程マスタテーブルは、製造処理部毎に設定されるもので、対応する製造処理部が１枚の基板を処理するのにかかる時間（製造装置１、検査装置２の各処理時間に装置１，２間における基板の搬送時間を合算した時間である。以下、この時間を「処理時間」という。）や、次の工程に１枚の基板を搬送するのにかかる時間（以下、「搬送時間」という。）が格納される。
【００３２】
基板状況テーブルおよび検査結果テーブルは、ラインに送り込まれた基板毎に設定される。図３は、これらのテーブルのデータ構成例を示す。なお、この図３では、複数のデータのいずれかを選択して格納される領域については、選択され得るデータを列挙し、そのうち、この例で選択されているデータを丸印で囲んで示す。
【００３３】
図３（１）に示す基板状況テーブルは、対応する基板が、現在、どの工程にどのような状態でいるかを示すものである。このテーブルには、基板を特定するための情報として、基板ＩＤおよびライン投入番号が格納されるほか、ライン番号、現処理工程、処理状況、処理開始時刻、処理終了時刻、処理開始予定時刻などの情報が格納される。
【００３４】
『基板ＩＤ』は、各基板に固有の識別コードである。『ライン投入番号』は、ラインへの基板の投入順に設定されるシリアル番号であって、基板ＩＤと同様に、基板毎に固有の情報である。ただし、目視確認により不良が確認されて、基板がラインから除去され、修正作業後にラインに再投入される場合には、『基板ＩＤ』は書き換えられないが、『ライン投入番号』は新たな番号に書き換えられる。『ライン投入番号』は、ラインの先頭の印刷処理部１１、または図示しないライン統括用の制御部により付与される。
【００３５】
『ライン番号』は、基板が投入されるラインの識別コードである。『現処理工程』とは、現在、基板を管轄している工程であって、各工程の略号であるＰ，Ｚ，Ｓ、および全ての工程を終了したことを示すデータ「Ｅｎｄ」のうちのいずれかが格納される。なお、各工程とも、自工程の入口（図示しない受付装置が配備されている地点）から次の工程の入口の手前までを管轄範囲とする。基板状況テーブルの『処理状況』は、この管轄範囲における基板への具体的な処理の内容を示すもので、基板受付部に待機している場合には「待ち」が、製造または検査が行われている場合には「処理中」が、次工程への搬送が行われている場合には「搬送中」が、それぞれ選択される。
【００３６】
『処理開始時刻』は、管轄の工程の製造装置１による処理が開始された時刻であり、『処理終了時刻』は、管轄の工程の検査装置２による検査が終了した時刻である。これらはいずれも現実の時刻なので、実際に処理が開始または終了するまで書き込まれない。
【００３７】
『処理開始予定時刻』は、サーバ装置３の予測処理により、製造処理部による処理が開始される時刻として割り出された時刻である。この予測処理は、処理が開始される前の待機状態の基板、および処理が終了して次の工程への搬送が開始された基板に対して行われる。すなわち、ある工程の検査を終了した基板について、次の工程が開始される時刻を予測することになる。
【００３８】
（２）−１の検査結果テーブルは、基板全体の総合的な検査結果を示すもので、ラインを流れる基板毎に作成され、検査の都度、書き換えられる（または検査毎に異なるテーブルが作成される場合もある。）。このテーブルには、基板ＩＤ、処理工程、検査結果（ＯＫまたはＮＧ）、目視結果（ＯＫ、ＮＧ、Ｎｕｌｌのいずれか）などが格納される。なお、目視結果の「Ｎｕｌｌ」は、目視確認作業がまだ行われていないことを示すものである。
【００３９】
（２）−２のＮＧデータテーブルは、不良判定された基板について、不良判定部位毎に作成されるもので、不良判定部位を特定するためのデータとして、基板ＩＤおよび被検査ＩＤが格納される。さらに、この部位の目視検査を担当した端末装置４のＩＤ、自動検査の結果（ＮＧのみ）、および目視結果（ＯＫ、ＮＧ、Ｎｕｌｌのいずれか）が格納される。なお、このＮＧデータテーブルも、検査結果テーブルとともに、検査結果テーブルデータベース３０３に格納される。
【００４０】
図２に戻って、上記した３種類のデータベース３０１，３０２，３０３に対するデータの格納処理は、情報収集処理部３０５により行われる。情報収集処理部３０５は、基板状況テーブルデータベース３０２や検査結果テーブルデータベース３０３に対しては、所定の時間毎に新しい情報の配信を受け付けてテーブルの内容を書き換える。一方、工程マスタテーブルデータベース３０１については、原則として、システムの立ち上げ時などに、各工程から情報を取り込んでテーブルに書き込むのみであり、その後は更新しない。
【００４１】
さらにサーバ装置３には、画像データベース３０４や、この画像データベース３０４に格納する画像を各検査装置２から受け付けるための画像入力部３１３が設けられる。画像データベース３０４には、各検査装置２の検査に使用された画像が部品単位のファイルとして格納されている。各画像には、基板および部品の識別コード（以下、それぞれを「基板ＩＤ」、「部品ＩＤ」という。）ならびに検査を実行した工程の略号（Ｐ，Ｚ，Ｓ）を含むファイル名が付されているので、これらの情報を特定することによって、検査に使用された画像を読み出すことができる。
【００４２】
上記のほか、サーバ装置３には、処理開始時刻予測部３０６、確認待ち行列生成部３０７、確認待ち行列記憶部３０８、割当処理部３０９、目視結果入力部３１０、行列更新部３１１、目視結果書込部３１２、アクセス受付部３１４、画像読出部３１５などが設けられる。これらは、いずれも、サーバ装置３の図示しないＣＰＵを含むハードウェアとプログラムとが協同することにより設定される機能である。
【００４３】
処理開始時刻予測部３０６は、工程マスタテーブルや基板状況テーブルを参照して、各工程の待機状態または搬送中の基板について、前記した処理開始予定時刻を求める処理を実行する。具体的な時刻算出方法については後記する。
【００４４】
確認待ち行列生成部３０７は、各基板の検査結果テーブルや、不良判定された基板のＮＧデータテーブルを用いて、各工程で不良と判定された基板や具体的な不良判定部位を認識し、その部位毎に、端末装置４に目視確認を要求するコマンド（以下、「確認要求コマンド」という。）を設定する。この確認要求コマンドには、目視確認の対象部位に対応する画像ファイルのファイル名が含まれている。
【００４５】
さらに確認待ち行列生成部３０７は、不良と判定された基板について、処理開始時刻予測部３０６から処理開始予定時刻を取り込み、その時刻が早い基板に対応するものから順に、確認要求コマンドを配列する。この配列により生成されたデータ列を、「確認待ち行列」という。生成された確認待ち行列は、確認待ち行列記憶部３０８に保存される。
【００４６】
割当処理部３０９は、各端末装置４との通信により、係員がおり、かつ目視確認処理が行われていない端末装置４を「目視確認の要求を受付可能な端末」と認識し、認識した端末装置４に、確認待ち行列の先頭の確認要求コマンドを割り当てる。そして、割り当てた確認要求コマンドを、そのコマンドを割り当てた端末装置４に送信することにより、対象の被検査部位を特定した目視確認処理を要求する。
【００４７】
端末装置４では、上記の確認要求コマンドを受け付けると、そのコマンド中の画像ファイル名を、リンク付きデータとしてモニタに表示する。係員がこのリンク付きデータをクリックすると、そのデータは、サーバ装置３のアクセス受付部３１４を介して画像読出部３１５に送られる。画像読出部３１５は、データの内容に基づき画像データベース３０４を検索して、対応する画像を読み出す。読み出された画像は、アクセス受付部３１４を介して、アクセスを行った端末装置４に返送される。
【００４８】
端末装置４では、送信された画像をモニタに表示する。係員は、この表示画面により不良判定部位の状態を目視確認し、判断の結果を示すデータ（ＯＫまたはＮＧ）を入力する。入力されたデータは、サーバ装置３の目視結果入力部３１０に送信された後、行列更新部３１１や目視結果書込部３１２に渡される。
【００４９】
目視結果書込部３１２は、供給された目視結果データを、該当する基板の検査結果テーブルやＮＧデータテーブルを書き換える。すなわち、各テーブル中の目視結果データを、ＮｕｌｌからＯＫまたはＮＧに書き換えることになる。行列更新部３１１は、割当処理部３０９による確認要求コマンドの割り当てに応じて、確認待ち行列の先頭のコマンドを消去する。また、目視結果入力部３１０から供給された目視結果データが「ＮＧ」であったときは、行列更新部３１１は、その目視結果に対応する基板について、確認待ち行列に確認要求コマンドが残っていないかどうかを確認し、残っていれば、消去する。
【００５０】
図４は、確認要求コマンドの構成およびコマンドの割り当て処理の方法を、模式的に示す。この例では、個々の不良判定部位に対応する確認要求コマンドを丸印に置き換えて、確認待ち行列の構成を表している。各コマンド内の数字は、各基板の処理開始予定時刻を早いものから順に並べたときの順序を表す。また、この図では、４台の端末装置４を、それぞれ「端末Ａ」「端末Ｂ」「端末Ｃ」「端末Ｄ」として示す。
【００５１】
図４の確認待ち行列には、４枚の基板につき生成された確認要求コマンドが含まれている。４枚のうち処理開始予定時刻が最も早い基板（「１」が付されたコマンドに対応するもの）には、７個の不良判定部位があり、そのうちの２個が、端末Ｂ，Ｃで目視確認されている。この例では、残り２台の端末装置４のうち、端末Ａが処理が可能な状態にあるので、この端末Ａに確認待ち行列の先頭の確認要求コマンドが送信される。さらに、処理中の端末Ｂ，Ｃの処理が終了したり、端末Ｄに係員が戻ってきた場合には、これらの端末装置４に、確認待ち行列のつぎの確認要求コマンドが送信されることになる。
【００５２】
図５は、目視確認処理で不良判定が行われた場合の確認待ち行列の更新例を示す。この図の上段は、図４に示した割り付け処理が行われて、端末Ａに送信した先頭の確認要求コマンドが消去された状態を示す。この状態下で端末Ａから「ＮＧ」の目視結果データが送信されたものとすると、図５の下段に示すように、行列更新部３１１によって、確認待ち行列に残っていた１枚目の基板の確認要求コマンドがすべて消去され、２番目の基板の確認要求コマンドが繰り上げられる。これにより、明らかな不良によりラインから回収される基板を目視の対象から外し、目視確認に待機している基板を優先的に処理することができるので、目視確認の効率を向上させることができる。
【００５３】
なお、端末装置４側の処理に余裕がある場合には、先頭から削除したコマンドを確認待ち行列の最後尾に配置して、目視確認を行うようにしてもよい。
【００５４】
図６は、ライン１，２で不良判定された基板に対し、従来の方法による目視確認処理を行う場合の検査結果と処理の流れとの関係を示す。この例では、ライン１，２とも、実装工程（Ｚ）からリフロー工程（Ｓ）に向けて、４枚の基板が流されるものとして、Ｚ，Ｓの工程および基板毎に、自動検査により不良と判定された部位の数（不良判定数）と、目視により不良と判定された部位の数（実不良数）とを対比させたテーブルと、基板毎のタイムチャートとを、左右に対応づけて示している。各テーブルの『ＩＤ』は、前出の基板ＩＤである。いずれのラインでも、この基板ＩＤが若い基板から順に搬送して、この図に示していない印刷工程（Ｐ）、およびＺ，Ｓの各工程を順次実行する。
【００５５】
なお、図６および次の図７では、同一基板に対する各工程間の処理の切り替わりを、矢印により示している。またタイムチャート中の「処理」には、製造装置１における処理と検査の双方が含まれる。また太枠部分は、処理の終了した基板を次工程またはラインの終端に搬送している期間にあたり、目の細かい網点パターンで示す期間は、目視確認処理の期間を示す。
【００５６】
図６の従来例では、各ラインの各工程毎に、それぞれ１台の専用の端末装置４が設置され、各工程で不良判定された基板の目視確認処理を、それぞれその工程を担当する端末装置４でのみ確認する。このような処理を行う場合、１枚の基板に多数の不良判定部位があると、その基板に対する確認作業が長引き、その結果、処理待ちの時間が長くなって、後続の基板の処理に影響を及ぼす場合がある。
【００５７】
たとえば、図６の例では、ライン１の実装工程（Ｚ）において、最初の基板（ＩＤ：１００１）に１０個の不良判定部位があり、次のリフロー工程（Ｓ）への搬送が終了しても目視確認が終了しなかったため、この基板に対するリフロー工程の開始が遅れている。また、１番目の基板の目視確認処理が長引いたことにより、つぎの基板（ＩＤ：１００２）に対する目視確認の開始が遅れ、その結果、この基板に対するリフロー工程の開始も遅れている。さらに、この２枚目の基板の処理の遅れによって、３、４枚目の基板（ＩＤ：１００３，１００４）に対するリフロー工程に大幅な遅れが生じている。
【００５８】
またライン２では、実装工程（Ｚ）において、２番目の基板（ＩＤ：２００２）に多数の不良判定部位があって目視確認が長引いた上に、実際に不良の部位があることが確認されて、この基板を取り除く作業が行われている。この間に、後続の３枚目、４枚目の基板（ＩＤ：２００３、２００４）がリフロー工程に到着しているが、３枚目の基板に対する目視確認処理の開始が遅れた上に、この３枚目の基板にも多数の不良判定部位があったため、目視確認処理の時間が長くなっている。この結果、３，４枚目の基板に対するリフロー工程は、大幅に遅れて開始されている。
【００５９】
図７は、図６の例と同様の検査結果に対し、図３に示した割り当て処理を実行する場合の処理の流れを示す。この例では、すべてのライン、全ての工程で生じた不良判定部位をとりまとめ、目視確認を急ぐものから順に、処理が可能な端末装置４に割り当てる。この割り当ては、個々の不良判定部位毎に行われるので、ライン１の１番目の基板のように、不良判定部位が多い基板があっても、複数の端末装置４で分担して確認作業を行うことができる。この結果、いずれの基板でも、従来例に比べて目視確認期間が大幅に短縮されるので、図７の例のように、搬送時間内に目視確認を終了することが可能になる。
【００６０】
また、ライン２では、２番目の基板に実際に不良箇所があって、ラインから基板を取り除く必要があるが、この例では複数の端末装置４で目視確認作業を分担でき、しかも不良が確認された段階で処理を打ち切るので、図６の例より格段に早く目視確認処理を終了することができる。この結果、後続の基板についても、搬送時間内に目視確認を終了することができるので、リフロー工程に到着後すぐに処理を開始できる状態となっている。
【００６１】
以下、図８〜１１を用いて、サーバ装置３の具体的なアルゴリズムを説明する。
まず、図８および図９は、確認待ち行列の生成処理（処理開始予定時刻の算出を含む。）の流れを示す。この処理では、各ラインの各工程について、ライン数の若い順、および上流から下流に向かう順に、ＳＴ１０１〜１１８のループを実行する。
【００６２】
このループでは、まず、ＳＴ１０２において、着目中の工程について、工程マスタテーブルから、処理時間Ｖおよび搬送時間Ｗを読み出す。つぎにＳＴ１０３において、ライン番号および工程の略号に基づき、基板状況テーブルデータベース３０２から着目中の工程の管轄下にある基板の基板状況テーブルを読み出し、図示しない作業用メモリに保存する。
【００６３】
つぎに読み出した各テーブルの処理状況データをチェックする。ここで、処理状況データが「搬送中」のテーブルがあれば、ＳＴ１０４が「ＹＥＳ」となり、その「搬送中」の基板について、以下のＳＴ１０５およびＳＴ１０６を実行する。
【００６４】
「搬送中」の基板は、製造装置１における処理および検査が終了した基板であるから、その基板状況テーブルには、処理終了時刻が書き込まれているはずである。ＳＴ１０５では、この処理終了時刻を読み出し、その時刻に搬送時間Ｗを加えた時刻Ｔを算出する。つぎのＳＴ１０６では、Ｔの値を、「搬送中」の基板の処理開始予定時刻として、基板状況テーブルに保存する。
【００６５】
つぎに、ＳＴ１０３で読み出された基板状況テーブルの中に、処理状況データが「待機中」のものがある場合には、ＳＴ１０７が「ＹＥＳ」となり、ＳＴ１０８〜１１７の処理を実行する。
【００６６】
ＳＴ１０８では、ＳＴ１０３で読み出された基板状況テーブルの中に、処理状況データが「処理中」のテーブルがあるかどうかをチェックする。このテーブルが存在する場合、すなわち着目中の工程で所定の基板を処理している場合には、ＳＴ１０８が「ＹＥＳ」となってＳＴ１０９に進み、その処理中の基板の処理開始時刻に、ＳＴ１０２で読み出した処理時間Ｖを加えた時刻Ｔ０を求める。一方、処理中の基板がない場合には、ＳＴ１０８が「ＮＯ」となってＳＴ１１０に進み、現在時刻をＴ０とする。
【００６７】
上記の時刻Ｔ０は、待機中の先頭の基板に対する処理が開始される時刻に相当すると考えられる。以下では、待機中の基板毎に、ＳＴ１１１〜１１５のループが実行される。
【００６８】
このループのＳＴ１１２では、まず他の待機中の基板の基板状況テーブルを用いて、ライン投入番号が着目中の基板より若い基板（すなわち、着目中の基板より先に処理される基板である。）の数Ｎを求める。ＳＴ１１３では、先の時刻Ｔ０に（Ｎ×Ｖ）時間を加えた時刻を求め、これを時刻Ｔとする。ＳＴ１１４では、このＴを着目中の基板の処理開始予定時刻として、その基板の基板状況テーブルに保存する。
【００６９】
このようにして、待機中の基板毎に処理開始予定時刻を求めると、ＳＴ１１６では、これらのうち最も遅い時刻と現在時刻との差を求め、これを待機中基板の最大待ち時間とする。ＳＴ１１７では、着目中の工程の１つ上流の工程の管轄にある搬送中基板の処理開始予定時刻を、その時刻にＳＴ１１６で求めた最大待ち時間を加えた時刻と比較し、より遅い方の時刻を処理開始予定時刻とする。ただし、最初の工程である印刷工程については、ＳＴ１１６，１１７はスキップされる。
【００７０】
このように、待機状態にある基板については、その基板を管轄する工程の処理時間と先行の基板の数とに応じて、待機中の処理の処理開始予定時刻が算出される。また、処理を終了してつぎの工程に搬送されている基板については、その基板がつぎの工程に到着する時刻と先行の基板の数とに基づき、つぎの工程の処理の処理開始予定時刻が算出される。
【００７１】
すべてのライン、工程の組み合わせについて、ＳＴ１０１〜１１８のループが実行されると、ＳＴ１１９では、処理状況データが「搬送中」または「待機中」の基板の検査結果テーブルを参照して、不良と判定された基板の基板ＩＤを抽出する。ＳＴ１２０では、ＳＴ１１９で抽出された基板ＩＤ毎に、そのＩＤが格納された基板状況テーブルから処理開始予定時刻を読み出す。さらにＳＴ１２１では、各基板ＩＤを、処理開始予定時刻の早いものから順にソートする。このソート処理により、不良と判定された基板は、その判定がされてから次の工程の処理が開始されるまでの時間が短いものから順に、並べられることになる。
【００７２】
ＳＴ１２２では、ソートされた各基板ＩＤにリンクするＮＧデータテーブルから、それぞれ基板ＩＤおよび被検査部位ＩＤを読み出し、この２種類のＩＤを用いて確認要求コマンドを作成する。すなわち、不良判定部位毎に、確認要求コマンドが作成されることになる。ＳＴ１２３では、作成されたコマンドデータを、基板ＩＤのソート後の順序に沿って配列する。さらに、ＳＴ１２４では、ＳＴ１２３の処理により生成されたデータ列を、確認待ち行列として、確認待ち行列記憶部３０８に保存する。
【００７３】
上記の確認待ち行列の生成処理は、データベース３０２，３０３が更新される毎に実行される。この場合に、確認待ち行列記憶部３０８に一段階前の確認待ち行列が残っていても、ＳＴ１２４では、これを消去し、新たな確認待ち行列を保存する。しかし、処理開始予定時刻については、一段階前の算出値を保持しておき、各工程の管轄に新たに入った基板のみを対象に、処理開始予定時刻を算出してもよい。ただし、端末装置４の目視確認処理で「不良」と判定されてラインから取り除かれた基板の後続基板について、確認要求コマンドが確認待ち行列に残っている場合には、データベース３０３内の先行基板の検査結果テーブルに「ＮＧ」が書き込まれたときに、後続基板の処理開始予定時刻を更新しておくのが望ましい。
【００７４】
図１０は、確認待ち行列の各確認要求コマンドを端末装置４に割り当てる処理の流れを示す。
この実施例の端末装置４は、自装置の稼働状態や入力データに基づき、「処理ＯＫ」「処理中」「離席中」のいずれかを示す状況データを定期的にサーバ装置３に送信している。図１０の最初のステップであるＳＴ２０１では、この状況データの送信を受け付け、現在、処理が可能な端末装置４があるかどうかを確認する。
【００７５】
ここで処理が可能な端末装置４があり、また確認待ち行列が保存されている場合には、ＳＴ２０２，２０３が「ＹＥＳ」となってＳＴ２０４に進む。ＳＴ２０４では、確認待ち行列の先頭のコマンドを処理が可能な端末装置４に送信する。ＳＴ２０５では、この送信したコマンドを、確認待ち行列から削除する。
【００７６】
ＳＴ２０１〜２０５の処理は、サーバ装置３に処理終了指令が入力されるまで繰り返し実行される。処理が可能な端末装置４がない場合または確認待ち行列が保存されていない場合も、処理終了指令が入力されない限り、ＳＴ２０１に戻って、同様の処理を繰り返す。処理終了指令が入力されると、ＳＴ２０６が「ＹＥＳ」となり、一連の処理を終了する。
【００７７】
図１１は、端末装置４からの目視確認結果の送信を受け付けて、確認待ち行列や検査結果テーブルを更新する処理の流れを示す。なお、この処理でも、処理終了指令が入力されるまで、繰り返し実行される。
【００７８】
端末装置４から送信される目視確認結果には、判断結果を示すＯＫまたはＮＧのデータのほか、対応する確認要求コマンドに含まれていた基板ＩＤ、被検査部位ＩＤが含まれている。サーバ装置３では、いずれかの端末装置４からのデータ送信を受け付けると、ＳＴ３０１からＳＴ３０２に進み、送信された各種データを入力する。さらに、ＳＴ３０３では、受け付けたデータに含まれている基板ＩＤおよび被検査部位ＩＤに基づき、受信データに対応するＮＧデータテーブルを特定し、そのテーブルに受信した目視結果データを書き込む。
【００７９】
さらに書き込んだ目視結果データが「ＮＧ」であれば、ＳＴ３０４が「ＹＥＳ」となってＳＴ３０５に進み、確認待ち行列から同じ基板ＩＤに対応する確認要求コマンドを削除する。さらに、ＳＴ３０６では、上記の基板ＩＤに対応する検査結果テーブルを特定し、その目視結果に「ＮＧ」を書き込む。
【００８０】
一方、ＳＴ３０３で書き込まれた目視結果データが「ＯＫ」であれば、ＳＴ３０４からＳＴ３０７に進み、同じ基板ＩＤに対応するコマンドが確認待ち行列中に残っているかどうかを、さらにつぎのＳＴ３０８で当該コマンドを処理中の端末装置４があるかどうかを、それぞれチェックする。ここで該当するコマンドが行列中に残っておらず、他の端末装置４で処理されていることもなければ、今回取得した目視結果データが、対応する基板にかかる最終の目視確認処理に対応することになる。よって、この場合には、ＳＴ３０７，３０８の判定が共に「ＮＯ」となってＳＴ３０９に進み、該当する基板の検査結果テーブルの目視結果に「ＯＫ」を書き込む。一方、ＳＴ３０７およびＳＴ３０８のいずれかが「ＹＥＳ」となった場合には、ＳＴ３０９の処理はスキップされる。なお、図示していないが、ＳＴ３０６やＳＴ３０９では、目視結果データに対応するＮＧデータテーブルについても、検査結果テーブルと同様のデータ更新を行う。
【００８１】
上記のように、この実施例では、各検査装置２で不良と判定された基板について、その検査後の工程の処理が開始される時刻が早いものから順に目視確認処理を行うとともに、１枚の基板に複数の不良判定部位がある場合には、これらの部位に対する目視確認処理を複数の端末装置４で分担できるようにしたから、目視確認処理に要する時間を従来より大幅に短縮でき、また、係員の負荷がばらつくのを防止することができる。よって、ラインにおける基板の停滞を防止することができ、基板の生産効率を向上することが可能になる。
【００８２】
ただし、各工程の製造処理部では、従前と同様に、前工程の検査で不良と判定された基板については、目視確認処理が終了し、不良判定部位がすべて「ＯＫ」でなければ処理を開始しない。したがって、仮に、端末装置４側の処理が混雑するなどして、不良判定された基板が次工程に到着するまでに目視確認を終了できなかった場合でも、目視確認の終了前に処理が開始されることはなく、基板の品質を確保することができる。
【００８３】
なお、上記実施例では、最終工程のリフロー工程についても、ライン終端を「次の工程」とみなして処理開始予定時刻を算出しているが、リフロー工程後の基板の確認は、ライン終端から基板を回収した後で行っても支障はない。したがって、印刷工程および実装工程で不良判定された基板のみを対象に、処理開始予定時刻を算出して確認待ち行列を作成した後に、リフロー工程で不良判定された基板に対応する確認要求コマンドを、確認待ち行列の後尾に付加してもよい。ただし、リフロー炉の後段に、プローブを用いた導通検査の工程が設けられている場合には、導通検査に要する時間や、リフロー工程から導通検査の工程への搬送時間などに応じて、リフロー工程における「次の工程の処理開始予定時刻」を求め、その時刻を反映した確認待ち行列を生成するようにしてもよい。
【００８４】
さらに上記したコマンド割り付け処理には、以下のような処理を加えることができる。
（１）所定の条件に応じて、複数の確認要求コマンドを１台の端末装置４に送信できるようにする。たとえば、同じ基板に対応する不良判定部位の数をｎ、一人の係員が１つの部位の目視確認に要する平均時間をｔとした場合、ｎ×ｔの値が上記基板の処理開始予定時刻までの待ち時間より小さければ、そのｎ個の不良判定部位に対応する確認要求コマンドを１台の端末装置４に送信する。
【００８５】
（２）確認待ち行列から削除したコマンドについても、別途、処理対象とする。すなわち、目視確認処理で実際に不良があると判断された基板について、確認待ち行列から削除した確認要求コマンドを、別の確認待ち行列として配列し、この行列のコマンドを端末装置４側の処理に余裕があるときに処理させる。実際に不良があると判断された基板はラインから回収された後、不良部位が修正されてラインに再投入されるが、この場合、前の検査で不良と判定された「見過ぎ」の部位について、再度、不良判定がなされる可能性がある。しかし、上記の方法により、修正後の再投入の前に未確認の不良判定部位の目視確認を完了し、その結果をＮＧデータテーブルに書き込んでおけば、同じ部位が再び不良と判定されても、そのＮＧデータテーブルを参照することにより、「見過ぎ」判定であると判断して、目視確認の対象から外すことができる。
【００８６】
なお、上記の処理は、必ずしも、確認待ち行列から削除したすべてのコマンドについて行う必要はない。たとえば、目視確認処理により多数の部位が「不良」と判断されたり、修正が困難な部位が「不良」と判断された場合には、修正を行わずに基板を廃棄することがある。このように、修正対象の基板が選択される場合には、「不良」と判断された部位の数や、不良と判断された部位の被検査部位ＩＤなどに基づき、修正作業が選択される基板に対応する確認要求コマンドのみを抽出して、上記（１）の処理の対象とするのが望ましい。
【００８７】
（３）不良の発生率に基づいて確認要求コマンドの配列順序を決定する。たとえば、あらかじめ、過去の同一種類の基板につき作成されたＮＧデータテーブルを用いて、被検査部位毎に、自動検査および目視確認結果がともに「ＮＧ」となった回数を計数し、その回数の全検査数に対する比率（実際の不良の発生率に相当する。）を算出する。確認待ち行列の生成処理では、同一基板または処理開始予定時刻が同じ基板に対応する不良判定部位の確認要求コマンドを、上記の不良の発生率が高い順に配列する。このようにすれば、実際に不良である可能性の高いものから目視確認を行うことができるから、不良が早期に発見される可能性が高められる。また、確認要求コマンドの数が少なかったり、処理開始予定時刻までに余裕があるような場合には、処理開始予定時刻を考慮せずに、不良の発生率のみに基づき各コマンドを配列してもよい。
【００８８】
（４）各係員が担当する対象部位を決めておき、目視確認の対象部位を担当者に優先的に割り当てる。不良判定部位の目視確認処理では、処理の都度、確認対象部位が異なるよりも、同種の部位を続けて確認した方が、効率が良く、判断の精度も高くなるとと思われる。そこで、あらかじめ、各係員の担当する部位を定めておき、同一基板または処理開始予定時刻の差が所定値以内の基板に対応する複数の不良判定部位を、それぞれの担当者の端末に割り付ける。ただし、特定の係員に負荷が偏るのを防止するために、一人の係員に割り当てる数に制限を設けたり、担当の係員への割当数が制限値を超える場合には、他の係員の端末装置４にも割り当てるなど、柔軟性をもたせた処理にする必要がある。
【００８９】
（５）目視担当の係員の習熟度や不良発生部位の種類を考慮して割当処理を行う。不良発生部位によっては、十分な経験を積んだ係員でなければ、正確な目視確認を行えない場合があるからである。
【００９０】
たとえば、あらかじめ、目視の難しい部位の被検査部位ＩＤを集めたリストをサーバ装置３に登録しておき、不良発生部位のＩＤがこのリストに入っている場合には、対応する確認要求コマンドの送信先を、習熟度の高い係員の端末装置４に限定する。この場合に、この係員が離席または処理中でコマンドを送信できず、他の端末装置４が処理可能な状態であれば、その空き端末には後のコマンドを送信して処理を進めるようにしてもよい。
【図面の簡単な説明】
【００９１】
【図１】基板生産ラインの構成例を示すブロック図である。
【図２】サーバ装置の機能ブロック図である。
【図３】基板状況テーブル、検査結果テーブル、ＮＧデータテーブルの構成例を示す説明図である。
【図４】確認待ち行列の構成および端末装置に対する割当処理の方法を示す説明図である。
【図５】目視確認処理でＮＧ判定がされた場合の処理例を示す説明図である。
【図６】従来の方法で目視確認処理を行う場合の検査結果と処理の流れとの関係を示す説明図である。
【図７】図４の方法により目視確認処理の割当を行った場合の検査結果と処理の流れとの関係を示す説明図である。
【図８】確認待ち行列の生成処理に関する処理の手順を示すフローチャートである。
【図９】図８の続きのフローチャートである。
【図１０】割当処理の手順を示すフローチャートである。
【図１１】目視確認結果の受信に伴うデータ更新処理の手順を示すフローチャートである。
【符号の説明】
【００９２】
１ 製造装置
２ 検査装置
３ サーバ装置
４ 端末装置
１０ 基板生産システム
１１ 印刷処理部
１２ 実装処理部
１３ リフロー処理部
３０５ 情報収集処理部
３０６ 処理開始時刻予測部
３０７ 確認待ち行列生成部
３０９ 割当処理部
３１０ 目視結果入力部
３１１ 行列更新部
【特許請求の範囲】
【請求項１】
複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各検査装置で不良と判定された被検査部位の画像をライン外の複数の端末装置に表示して、目視確認のための処理を実行させるために、各端末装置の処理対象を管理する方法であって、
各製造処理部および端末装置は、それぞれ共通のサーバ装置に接続されており、各製造処理部は、管轄する基板の処理状況データおよび検査結果データをサーバ装置に送信する処理を、各端末装置は、自装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データをサーバ装置に送信する処理を、それぞれ繰り返し実行し、
前記サーバ装置は、
各製造処理部から送信された検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識するステップＡ、
各工程における処理時間および工程間における基板の搬送時間、ならびに各製造処理部から送信された各基板の処理状況データに基づき、前記ステップＡで認識された基板毎に、次の工程の処理が開始されるタイミングを予測するステップＢ、
前記不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドをステップＢで予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するステップＣ、
各端末装置から送信された稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、前記データ列の先頭部分の確認要求コマンドを送信するステップＤ、
の各ステップを実行することを、特徴とする基板生産ラインにおける目視確認処理の管理方法。
【請求項２】
前記ステップＢでは、最終の工程を除くいずれかの工程の検査装置で不良と判定されて次の工程に搬送される基板があるとき、前記次の工程の製造処理部から送信された処理状況データに基づき、当該次の工程が管轄する先行の基板の処理に要する時間を求め、前記次の工程に搬送される基板について、その搬送に要する時間から当該基板が次の工程の管轄に入る時刻を割り出し、その時刻から前記先行の基板の処理に要する時間が経過した時点の時刻を、前記次の工程の処理が開始される時刻として設定する、請求項１に記載された基板生産ラインにおける目視確認処理の管理方法。
【請求項３】
請求項１または２に記載された方法において、
前記確認要求コマンドを送信した端末装置から、そのコマンドに対応する目視確認結果を受け付けるステップＥと、このステップＥで受け付けた目視確認結果が不良である旨を示すとき、前記データ列から同一の基板に対応する確認要求コマンドを削除するステップＦとを、さらに実行する、基板生産ラインにおける目視確認処理の管理方法。
【請求項４】
複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各検査装置で不良と判定された被検査部位の画像を表示して、目視確認のための処理を実行する複数の目視確認用の端末装置に対し、それぞれの処理対象を管理するための装置であって、
各製造処理部から、それぞれその処理部が管轄する基板の処理状況データおよび検査結果データを収集する処理を、繰り返し実行する第１の情報収集手段と、
各端末装置から、それぞれその端末装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データを収集する処理を、繰り返し実行する第２の情報収集手段と、
前記第１の情報収集手段が各製造処理部から収集した検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する不良基板認識手段と、
各工程における処理時間および工程間における基板の搬送時間、ならびに第１の情報収集手段が収集した各基板の処理状況データに基づき、前記不良基板認識手段により認識された基板毎に、次の工程の処理が開始されるタイミングを予測する予測手段と、
不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを前記予測手段により予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するデータ列生成手段と、
前記第２の情報収集手段が各端末装置から収集した稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、前記データ列の先頭部分の確認要求コマンドを送信するコマンド送信手段とを、具備する基板生産ラインの管理用サーバ装置。
【請求項１】
複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各検査装置で不良と判定された被検査部位の画像をライン外の複数の端末装置に表示して、目視確認のための処理を実行させるために、各端末装置の処理対象を管理する方法であって、
各製造処理部および端末装置は、それぞれ共通のサーバ装置に接続されており、各製造処理部は、管轄する基板の処理状況データおよび検査結果データをサーバ装置に送信する処理を、各端末装置は、自装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データをサーバ装置に送信する処理を、それぞれ繰り返し実行し、
前記サーバ装置は、
各製造処理部から送信された検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識するステップＡ、
各工程における処理時間および工程間における基板の搬送時間、ならびに各製造処理部から送信された各基板の処理状況データに基づき、前記ステップＡで認識された基板毎に、次の工程の処理が開始されるタイミングを予測するステップＢ、
前記不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドをステップＢで予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するステップＣ、
各端末装置から送信された稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、前記データ列の先頭部分の確認要求コマンドを送信するステップＤ、
の各ステップを実行することを、特徴とする基板生産ラインにおける目視確認処理の管理方法。
【請求項２】
前記ステップＢでは、最終の工程を除くいずれかの工程の検査装置で不良と判定されて次の工程に搬送される基板があるとき、前記次の工程の製造処理部から送信された処理状況データに基づき、当該次の工程が管轄する先行の基板の処理に要する時間を求め、前記次の工程に搬送される基板について、その搬送に要する時間から当該基板が次の工程の管轄に入る時刻を割り出し、その時刻から前記先行の基板の処理に要する時間が経過した時点の時刻を、前記次の工程の処理が開始される時刻として設定する、請求項１に記載された基板生産ラインにおける目視確認処理の管理方法。
【請求項３】
請求項１または２に記載された方法において、
前記確認要求コマンドを送信した端末装置から、そのコマンドに対応する目視確認結果を受け付けるステップＥと、このステップＥで受け付けた目視確認結果が不良である旨を示すとき、前記データ列から同一の基板に対応する確認要求コマンドを削除するステップＦとを、さらに実行する、基板生産ラインにおける目視確認処理の管理方法。
【請求項４】
複数の工程毎に自動外観検査装置を含む製造処理部が設けられた基板生産ラインを少なくとも１ライン含む基板生産システムにおいて、各検査装置で不良と判定された被検査部位の画像を表示して、目視確認のための処理を実行する複数の目視確認用の端末装置に対し、それぞれの処理対象を管理するための装置であって、
各製造処理部から、それぞれその処理部が管轄する基板の処理状況データおよび検査結果データを収集する処理を、繰り返し実行する第１の情報収集手段と、
各端末装置から、それぞれその端末装置が目視確認の要求を受け付け可能な状態にあるか否かを示す稼動状況データを収集する処理を、繰り返し実行する第２の情報収集手段と、
前記第１の情報収集手段が各製造処理部から収集した検査結果データを用いて、不良と判定された基板およびその不良判定部位を認識する不良基板認識手段と、
各工程における処理時間および工程間における基板の搬送時間、ならびに第１の情報収集手段が収集した各基板の処理状況データに基づき、前記不良基板認識手段により認識された基板毎に、次の工程の処理が開始されるタイミングを予測する予測手段と、
不良判定された基板の不良判定部位毎に確認要求コマンドを設定し、各確認要求コマンドを前記予測手段により予測されたタイミングが早い基板に対応するコマンドから順に配列したデータ列を生成するデータ列生成手段と、
前記第２の情報収集手段が各端末装置から収集した稼動状況データに基づき、目視確認の要求を受け付け可能な端末装置を特定し、その装置に、前記データ列の先頭部分の確認要求コマンドを送信するコマンド送信手段とを、具備する基板生産ラインの管理用サーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−１３５５８１（Ｐ２００８−１３５５８１Ａ）
【公開日】平成２０年６月１２日（２００８．６．１２）
【国際特許分類】
【出願番号】特願２００６−３２１００１（Ｐ２００６−３２１００１）
【出願日】平成１８年１１月２９日（２００６．１１．２９）
【出願人】（０００００２９４５）オムロン株式会社 (3,542)
【公開日】平成２０年６月１２日（２００８．６．１２）
【国際特許分類】
【出願日】平成１８年１１月２９日（２００６．１１．２９）
【出願人】（０００００２９４５）オムロン株式会社 (3,542)
[ Back to top ]