(57)【要約】      （修正有）【課題】診断装置を、メンテナンス要員によるマニュアルプログラミングを必要とせずに広範囲のＵＵＴ機器モデルとインタフェース接続可能にする。【解決手段】データ取得装置は、通信インタフェース仕様と、試験する種々のクラスの機器によって出力された診断属性の他の特性とを記憶するためのデータベースを有している。データベースレコードは、１クラスの機器を識別する第１のフィールドと、該クラスの機器によってその値が出力される診断属性を識別する第２のフィールドと、第３のフィールドとを含む。第３のフィールドは、診断装置が、該レコードの第１のフィールドによって識別されているクラスのＵＵＴ機器から、第２のフィールドによって識別されている属性値を検索することができるＩＤ（例えば物理信号線、物理アドレスまたは論理アドレス）を特定可能である。または、第３のフィールドは、診断属性が送信される通信インタフェースを識別可能である。【選択図】図２
2011101023.tif 000002
【特許請求の範囲】
【請求項１】
診断装置により機器を試験する方法であって、
一つ以上のチャンバを有する機器の項目（item）に対する接続を検出するステップと、
前記機器の項目の機器クラスを決定するステップであって、前記機器クラスには前記機器の項目のバージョンとモデルとが含まれている、前記ステップと、
属性データベースから、前記機器クラスに一致する一つ以上の属性レコードを検索するステップと、
前記機器の項目に関連する一つ以上の属性の選択を受け取るステップであって、少なくとも一つの選択には、チャンバ位置とチャンバモデルの選択が含まれ、各属性は前記機器クラスの動作パラメータ又はセンサ測定結果である、前記ステップと、
選択された属性の各々に対して、前記選択された属性と前記機器の項目の前記機器クラスに対応する属性レコードを識別するステップであって、前記属性レコードには、前記属性と前記機器クラスに関連する識別子（identifier）と変換係数とが含まれ、前記属性レコードは、前記機器の項目から前記選択された属性値の検索を可能にする、前記ステップと、
前記属性レコードを使用して前記機器の項目から属性データを検索するステップと、
前記属性レコードに含まれる前記変換係数を使用して、前記属性データを物理的単位の測定結果に変換するステップと、
を備える、前記方法。
【請求項２】
前記属性レコードには、前記機器クラスを識別する第１フィールド、前記属性を識別する第２フィールド、前記識別子を特定する第３フィールドが含まれ、前記第１フィールドにより識別されている前記機器クラスが、前記第２フィールドにより識別されている属性に割り当てる、請求項１に記載の方法。
【請求項３】
前記属性データベースから、前記属性レコードに関連する下位レコードを検索するステップであって、前記下位レコードが一つ以上の下位フィールドを有し、前記下位フィールドが前記属性レコードの前記第２フィールドに対して下位にある、前記ステップを更に備える、請求項２に記載の方法。
【請求項４】
前記一つ以上の下位フィールドは、少なくとも一つの属性名称フィールド、属性チャンバモデルフィールド、読み取り／書き込みフィールド、単位変換フィールド、最小スケール係数変換フィールド、最大スケール係数変換フィールドを含む、請求項３に記載の方法。
【請求項５】
前記機器の項目の前記機器クラスを決定するステップは、前記機器クラスのユーザ選択を受け取り、更に、
ユーザが選択可能な機器クラスのリストを含むグラフィカルユーザインタフェースの第１ビューを表示する工程と、
前記機器クラスのユーザ選択を受け取る際に、前記機器クラスに関連するユーザが選択可能なリストを含むグラフィカルインタフェースの第２ビューを表示する工程と、
を備える、請求項１に記載の方法。
【請求項６】
前記診断装置は、携帯診断装置であって、前記属性データベースを含む、請求項１に記載の方法。
【請求項７】
前記属性レコードの各々は、前記機器クラスと通信するためのプロトコルと前記属性データとを検索するためにアナログ通信インタフェースまたはディジタル通信インタフェースを使用する表示を含む、請求項１に記載の方法。
【請求項８】
前記属性データベースは、前記診断装置から遠隔にあり、前記方法は、更に、
前記属性データベースから、前記一つ以上の属性レコードを検索する際に前記機器クラスと一致する前記一つ以上の属性レコードを記憶するステップを備える、請求項１に記載の方法。
【請求項９】
一つ以上のチャンバを含む機器の項目と接続するためのディジタル通信インタフェース及びアナログ通信インタフェースと、
複数の属性レコードを記憶するための属性データベースであって、一つ以上の前記複数の属性レコードは機器クラス、前記機器クラスに関連する属性、前記属性と前記機器クラスに関連する識別子、変換係数を含み、各属性は、前記機器クラスの動作パラメータ又はセンサ測定結果である、前記属性データベースと、
前記機器の項目の機器クラスを決定すること、前記機器の項目に関連する属性の選択であって、前記選択がチャンバ位置とチャンバモデルの選択を含む前記選択を受け取り、前記属性データベース内で前記選択された属性と前記機器の項目とを見つけるために、前記属性データベースに結合される属性ルックアップモジュールと、
前記属性レコードを使用して前記ディジタル通信インタフェース又は前記アナログ通信インタフェースを介して前記機器の項目から属性データを検索し、前記属性レコード内に含まれる前記変換係数を使用して物理的単位の測定結果に前記属性データを変換するためのデータコレクタと、
を備える、診断装置。
【請求項１０】
前記属性データベースは複数の下位レコードを記憶し、前記複数の下位レコードの各々が、一つ以上の前記複数の属性レコードに関連しており、前記複数の下位レコードの各々が、前記関連する一つ以上の前記複数の属性レコードのフィールドに対して下位にある一つ以上のフィールドを有し、
前記属性ルックアップモジュールは、前記属性データベースから、前記属性データベース内で前記選択された属性と前記機器の項目に関連する下位レコードを更に検索する、請求項９に記載の診断装置。
【請求項１１】
前記一つ以上の下位フィールドは、少なくとも一つの属性名称フィールド、属性チャンバモデルフィールド、読み取り／書き込みフィールド、単位変換フィールド、最小スケール係数変換フィールド、最大スケール係数変換フィールドを含む、請求項１０に記載の診断装置。
【請求項１２】
前記機器クラスに関連するユーザが選択可能な属性リストを表示するためにグラフィカルユーザインタフェースを更に備える、請求項９に記載の診断装置。
【請求項１３】
前記診断装置は、携帯診断装置である、請求項９に記載の診断装置。
【請求項１４】
前記属性レコードの各々は、前記機器クラスと通信するためのプロトコルと前記属性データとを検索するために前記アナログ通信インタフェース又は前記ディジタル通信インタフェースを使用するかの表示を含む、請求項９に記載の診断装置。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本特許出願は、２００３年３月１日に提出された米国仮特許出願第６０／４５１，３０１号の３５ＵＳＣ１１９（ｅ）の利点を請求するものである。
【発明の分野】
【０００２】
本発明は概して電子診断／データ取得装置に関する。より具体的には、本発明は、試験可能な種々のモデルやクラスの機器（「被試験ユニット」すなわち「ＵＵＴ」）を集計するための、またこのようなクラスのＵＵＴ機器ごとに（１）その値が該ＵＵＴによって送信可能な各診断属性と、（２）該ＵＵＴからその属性値を検索するための診断装置に必要なＩＤ（例えば物理信号線、物理アドレスまたは論理アドレス）およびその他の通信インタフェースパラメータとを集計するためのデータベース方法および装置を備えるこのような診断装置の改良である。
【発明の背景】
【０００３】
データ取得／データ収集装置とも呼ばれる診断装置は、一般に種々のタイプの電子機器を試験および修理するために使用される。診断装置は被試験電子機器（「被試験ユニット」すなわち「ＵＵＴ」）によって発生された電子データの値を監視する。このデータは概してＵＵＴの種々のセンサ測定結果および／または動作条件を表しており、そのすべては総合的にＵＵＴの「診断属性」、「収集可能な属性」あるいは単に「属性」と称される。メンテナンス要員は属性データを分析して、ＵＵＴの性能を修理または最適化する。
【０００４】
メンテナンス要員は通常、様々なタイプのこのような電子機器を試験および修理するために割り当てられる。概して異なるタイプおよびモデルのＵＵＴ機器は、データ通信インタフェースの数および種類、データインタフェースにて出力する属性、および選択された属性値をＵＵＴから検索するための診断装置に必要なＩＤ（物理信号線、物理アドレスまたは論理アドレス）に関して相互に異なっているために、診断機器への接続のための異なるインタフェース要件を課している。実際、異なるインタフェース要件が同一モデルの機器の異なる生産バージョン間にも存在する場合がある。
【０００５】
狭い範囲のＵＵＴ機器モデルとのみインタフェース接続するように適合されている従来の診断装置もある。より広範なＵＵＴ機器とインタフェース接続できるようにプログラミングされている従来の診断装置もあるが、このようなプログラミングは、装置が異なるモデルのＵＵＴへの接続を意図するたびに、メンテナンス要員によってマニュアルで入力されなければならない。
【０００６】
メンテナンス要員によるマニュアルプログラミングを必要とせずに広範囲のＵＵＴ機器モデルとインタフェース接続可能な診断装置に対する必要性がある。
【発明の概要】
【０００７】
本発明は、通信インタフェース仕様と、試験する種々のクラス（モデルおよび／またはバージョン）の機器（「被試験ユニット」つまり「ＵＵＴ」）によって出力された診断属性の他の特性とを記憶するためのデータベース（「属性データベース」）を有する診断器具すなわちデータ取得装置である。属性データベースは複数の属性データレコードを含んでおり、この各々は少なくとも、１クラスのＵＵＴ機器を識別する第１のフィールドと、
その値が該クラスの機器によって出力される診断属性を（名称や記述によって）識別する第２のフィールドとを含む。ＵＵＴによって出力された属性値（すなわち属性データ）はセンサ測定結果および動作条件を含んでいてもよい。
【０００８】
本発明の一態様において、属性データレコードはさらに、該レコードの該第１のフィールドによって識別された該クラスのＵＵＴ機器から、該第２のフィールドによって識別された属性値を診断装置が検索可能なＩＤ（例えば物理信号線、物理アドレスまたは論理アドレス）を識別する第３のフィールドを含む。例えば、ＩＤは、（ａ）該ＵＵＴが該属性値を出力する物理信号線またはコネクタピン、（ｂ）該ＵＵＴに該属性値の出力を命じるために診断装置が該ＵＵＴに送らなければならない論理または物理アドレス、あるいは（ｃ）該値が表している属性を識別するために該属性値に伴って該ＵＵＴが出力する論理または物理アドレスを識別することができる。
【０００９】
本発明の第２の態様において、該データベースで識別された少なくとも１クラスのＵＵＴ機器は、診断装置が属性データを検索可能な複数の通信インタフェースを含んでおり、属性データレコードはさらに、該通信インタフェースのうちの１つを識別するフィールドを含む。
【００１０】
本発明の第３の態様において、属性データレコードはさらに、１クラスの属性内の属性を区別するチャンバ位置や他の構成パラメータを識別するフィールドを含む。
【００１１】
本発明の第４の態様において、属性データレコードはさらに、該機器によって出力された電気信号を、該第２のフィールドによって識別された属性値に対する物理的単位の測定結果に変換するための、スケール係数などの１つ以上の変換パラメータを含有するフィールドを含む。
【００１２】
本発明の第５の態様において、属性データレコードの一部または全部の上記第１のフィールドは、該第１のフィールドによって識別された該クラスの機器を定義する一連の機器モデル、一連の機器バージョンまたは一連の機器改訂日を総合的に識別する複数の下位フィールド（サブフィールド）を含む複合フィールドである。
【００１３】
上記診断装置に加えて、本発明の他の態様は、上記属性データベース、上記に概説されている該属性データベースにデータを記憶するための方法および該方法を実行するためのデータ処理装置である。
【好ましい実施形態の詳細な説明】
【００１４】
従来のＵＵＴおよび診断装置
新規の診断装置およびデータベースについて説明する前に、概してＵＵＴが従来の診断装置と通信する様子について説明するのが有用であろう。
【００１５】
ＵＵＴ（「被試験ユニット」）は任意のタイプの電子機器であるのに対して、図１に示されている例示的ＵＵＴ１２は、本発明の譲渡人であるアプライドマテリアルズ社によってＰｒｅｃｉｓｉｏｎ５０００モデルとして市販されている半導体製作機器「メインフレーム」または「プラットフォーム」に類似している。図示されているメインフレームは、種々の半導体製作プロセスを実行する最大６個のプロセスチャンバ２１〜２６を一体化するように設計されている。例えば、３個のチャンバ２１、２２、２３はプラズマ化学気相成長（ＣＶＤ）チャンバであってもよく、チャンバ２４は加熱チャンバであってもよく、また２個のチャンバ２５および２６はプラズマエッチングチャンバであってもよい。
【００１６】
（実際のＰｒｅｃｉｓｉｏｎ５０００は、本明細書では図示を簡略化するために省略されているが、メインフレームの外部のキャリアから半導体ウェーハを受け取るためのロードロックチャンバ、およびチャンバ間でウェーハを転送するためのウェーハ転送ロボットなどの種々のコンポーネントを含む。）
ＵＵＴメインフレーム１２の機能の１つは、中央通信インタフェースつまり通信バス３１をチャンバに提供することである。各チャンバはメインフレームの対応する内部データポート３３に接続されているデータポート３２を有している。メインフレームの内部データポート３３はすべて共通の通信チャネル３１に接続されていてもよい。メインフレームは、プロセスチャンバで実行されている半導体製作プロセスのシーケンスおよび動作条件をコントロールし、またメインフレームの内部および外部データポートのすべてにおけるデータ転送をコントロールするコンピュータプロセッサ（ＣＰＵ）３０を含む。メインフレームは、チャンバ圧、台座温度およびＲＦ電力などの種々のチャンバ動作パラメータの値を設定するために、その内部データポートを介してデータをチャンバに送信することができる。
【００１７】
チャンバの各々はまた、センサや測定器具５０に取り付けられて、一定の波長でのガス圧、ＲＦ反射電力または光学発光の強度などの、チャンバの動作条件を測定することができる。メインフレームは、測定器具から測定値を受け取り、該測定器具をコントロールするためのコマンドを送るための追加の内部データポート５２を含んでいてもよい。
【００１８】
本明細書では単に「属性」と称されているＵＵＴ１２の診断属性つまり収集可能な属性は、２つの先行段落で説明されている動作条件および測定値のすべてを含む。具体的に、ＵＵＴ１２の「属性」は、その値がＵＵＴによって、ＵＵＴに接続されているチャンバ２１〜２６または他の装置によって、あるいはチャンバまたはＵＵＴに接続されている測定器具５０によって出力可能な１セットの動作条件およびセンサ測定結果として定義されている。ＵＵＴまたはＵＵＴに付随するチャンバや器具によって出力された属性値は総合的に「属性データ」と称される。
【００１９】
ＵＵＴ１２は、ファクトリコントローラコンピュータや診断装置１０などの外部デバイスに属性データを送信可能な少なくとも１つの外部通信インタフェースつまりＩ／Ｏ（入力／出力）ポートを有している。概して主要な外部通信インタフェースは、従来のＲＳ−２３２シリアルポートや従来のイーサネットポートなどのディジタルインタフェース１４である。ＵＵＴはまた、通常、アナログ出力信号５２を生成する測定器具５０から測定値を出力するための１つ以上のアナログ通信インタフェース１５を有していてもよい。
【００２０】
所与のタイプのＵＵＴを監視することを目的としている従来の診断装置１０は、該タイプのＵＵＴの外部通信インタフェースと互換性があり、かつそれに電気接続可能な１つ以上の通信インタフェース（Ｉ／Ｏポート）を有する。例えば、例示的ＵＵＴに接続するために、診断装置は、ＵＵＴのディジタルインタフェース１４およびアナログインタフェース１５にそれぞれ接続されているディジタル通信インタフェース１８と１つ以上のアナログ通信インタフェース１７とを有していなければならない。（図示するために、図１のＵＵＴはアナログインタフェースを含むのに対して、市販されているＰｒｅｃｉｓｉｏｎ５０００メインフレームはアナログインタフェースを含んでいない。）
加えて、一部のプロセスチャンバと測定器具は、ＵＵＴに接続されていないディジタルまたはアナログ通信インタフェース５４を介して属性データを出力することができる。この属性データを受け取るために、診断装置１０は、チャンバおよび測定器具の通信インタフェース５４に接続されている追加通信インタフェース１９を含むことができる。
【００２１】
属性データは、ＵＵＴによって、ＵＵＴに接続されているチャンバや他の装置によって、あるいはこのようなチャンバやＵＵＴに結合されている測定器具によって出力可能であるので、「属性データソース」や単に「データソース」という用語は、属性データを出力可能なＵＵＴに直接または間接に接続されている任意の装置を意味するのに本明細書では使用されている。さらに、ＵＵＴによって出力された属性データに対する本明細書での全参照は、ＵＵＴに直接または間接に接続されている属性データソースによって出力された属性データを含むことを意図している。
【００２２】
ＵＵＴや他の属性データソースが外部通信インタフェースを介してディジタルデータを出力可能な多数の従来のディジタル通信プロトコルは概して２つのカテゴリのいずれかに入る。つまりコマンド駆動プロトコルと連続ストリーミングプロトコルである。
【００２３】
コマンド駆動プロトコルにおいて、データソースは、そのディジタル通信インタフェースでデータソースが受け取った「読み取り」コマンドに応答してのみ、属性データを出力する。具体的には、診断装置１０は、データソースのディジタルＩ／Ｏインタフェース１４または５４に、その属性のＩＤを含む「読み取り」コマンドを送信することによってのみ特定の属性値をデータソースから受け取ることができる。論理アドレスや論理ポートとも呼ばれるＩＤは、ＵＵＴやその関連属性データソースが、出力可能な各属性を一意に識別するディジタル値である。「論理」とは、ＩＤは任意の物理アドレスや物理ポートに対応する必要がないことを意味している。
【００２４】
「読み取り」コマンドへの応答だけではなく、ディジタルＩ／Ｏインタフェース１４または５４を介して「書き込み」コマンドに応答する属性データソースもある。例えば、診断装置つまりファクトリコントローラコンピュータは、チャンバの動作パラメータを変化させるコマンドをＵＵＴに送ることができる。
【００２５】
ディジタルデータを出力するための連続ストリーミング通信プロトコルにおいて、ＵＵＴや他のデータソースは、その外部ディジタル通信インタフェース１４または５４を介して属性データの連続ストリームを出力する。属性データは通常、周期的に送信されたフレームとしてフォーマットされて、本明細書ではデータの各フレームは各属性の現在値を含有している。一部のデータソース装置において、各属性は、フレームにおけるそのシーケンス位置またはオフセットによって識別されているにすぎない。その場合、各属性のＩＤつまり論理アドレスはその位置またはオフセットである。他のデータソースにおいて、フレームは、各属性フィールドと関連したＩＤフィールドを含んでいてもよい。ＩＤフィールドにおいて送信されたＩＤ値は、その値が関連属性フィールドにおいて送信されている属性を識別する。
【００２６】
しばしば「トレースモード」プロトコルと呼ばれる連続ストリーミングプロトコルの変形例において、ＵＵＴまたは他の属性データソースは、連続ストリーミングフォーマットにおいて一定の属性値を出力するだけである。診断装置は、選択された属性を識別するデータソースに「トレースモード」コマンドを送ることによって、いずれの属性が「ストリーム」に含まれているかを選択することができる。
【００２７】
ＳＥＣＳ−２として知られている公知のデータ通信標準を実現する半導体製作機器は概して、コマンド駆動プロトコルおよびトレースモードプロトコルの両方を使用して属性データを出力することができる。
【００２８】
ＵＵＴおよびその関連属性データソースが、コマンド駆動プロトコル、連続プロトコル、またはこの両方のいずれを介してディジタル属性データを送信するかに関係なく、診断装置１０は、診断装置が使用される各クラスのＵＵＴについて各診断属性に対応するＩＤを知ることが重要である。
【００２９】
上記のとおり、ＵＵＴやその関連属性データソースはまた、アナログ出力信号の形態の属性データを生成する測定器具やセンサから測定値を出力するための１つ以上のアナログ通信インタフェース１５を有していてもよい。各アナログインタフェースは、各々が異なる属性のアナログ値を送信可能な１つ以上の信号線を有していてもよい。その場合、診断装置は、いずれの属性が各アナログインタフェースの各信号線に対応しているか（すなわちそれによって送信されるか）を知ることが重要である。
【００３０】
種々のメインフレームモデルは、それらが接続可能なプロセスチャンバ数が異なる。複数のチャンバ２１〜２６が接続可能なメインフレーム１２において、所与の属性値が適用するチャンバを識別することが重要である。従って、所与のクラスの診断属性はチャンバごとに異なるＩＤを有している。ある「クラス」の属性の一例はチャンバ圧である。第１のチャンバ２１のチャンバ圧と第２のチャンバ２２のチャンバ圧は異なるＩＤを有していることによって区別される。
【００３１】
種々のプロセスチャンバモデルは異なるクラスの属性を有している。例えば、ＲＦ電力は、熱成長チャンバではなくプラズマチャンバの属性であるのに対して、加熱ランプ電力は通常前者ではなく後者の属性である。別の例として、独立してコントロール可能な電力およびＲＦ周波数を具備する２個のＲＦ電源を有するプラズマチャンバがあるのに対して、１つのＲＦ電源しか有していないプラズマチャンバもある。
【００３２】
種々のメインフレームモデルはまた、プロセスチャンバのうちの１個ではなくメインフレーム自体に関し、またメインフレームの外部通信インタフェースで受け取りや送信が可能な異なるクラスの属性を有している。メインフレーム属性の一例はウェーハ転送ロボットの位置である。１個のロボットしか有していないメインフレームモデルがあるのに対して、２個有するものもあり、それによって前者のメインフレームは、第２のロボットの位置や、第２のロボットを収容する転送チャンバ内の圧力をコントロールするコマンドを受容しない。
【００３３】
異なるＵＵＴやメインフレームモデルが、チャンバ圧およびサセプタ温度などの共通の属性を有していることまで考えると、異なるメインフレームモデルは通常異なるＩＤをそれらの属性に割り当てている。例えば、あるメインフレームモデルについては、プロセスチャンバ番号１のチャンバ圧は「１２３４５」というＩＤを有しているのに対して、対応するチャンバ圧は第２のメインフレームモデルに対して「ＡＢＣ」というＩＤを有していてもよい。さらに、複数の外部通信インタフェースを有するＵＵＴは属性とインタフェースの対応、すなわち、診断装置ごとに、いずれのインタフェースと、そのインタフェース上のいずれの信号線がその属性を送信するかにおいて異なっていてもよい。
【００３４】
ＵＵＴはまた、属性を符号化するフォーマットが異なっている。例えば、その外部通信インタフェースを介して送信するディジタル値を温度および圧力などの物理属性に変換するのに必要な変換係数が異なっていてもよい。
【００３５】
上記のように複数のクラスのＵＵＴ間の多数の差異ゆえに、従来の診断装置は通常、診断装置が属性の検索方法を理解している１モデルまたは少数のモデルのＵＵＴからのデータ受け取りに制限されている。
【００３６】
属性データベース
新規の診断装置１０は上記の従来の診断装置に、診断装置１０が多数の異なるクラス（モデルおよび／またはバージョン）のＵＵＴ１２と通信することができる通信インタフェース仕様を含有する新規のデータベースを付加する。データベースは、各クラスのＵＵＴがその外部通信インタフェースを介して出力可能な属性リストを記憶している、本明細書では「属性テーブル」または「属性データベース」と称されているテーブルを含有している。属性ごとに、属性データベースは、診断装置がその属性の値を検索することができるＩＤを記憶している。
【００３７】
診断装置は、属性データベースを含むことを除いてあらゆる点で従来的であってもよい。「ハードウェア実現」という見出しの後で以下に説明されているように、データベースは任意の従来のデータ記憶デバイス６０に記憶されていてもよく、これは診断装置内に配置可能であり、あるいは離れて配置されて、通信ネットワークを介して診断装置に接続されていてもよい。
【００３８】
図２に示されている実施形態において、属性データベースはＵＵＴのクラスおよび属性の組み合わせごとに明確なデータベースレコードを含有している。つまり、属性データベースは各クラス（モデルまたはバージョン）のＵＵＴ機器に対して明確なグループ（つまり「セット」）のレコードを含有しており、所与のメインフレームクラスに対する１セットのレコードは、そのメインフレームクラスに対して送信および受け取り可能な各属性の明確なレコードを含む。（必要なレコード数を削減するための代替実施形態については、「バージョン範囲」および「データベース正規化」という見出しの後に説明する。）
上記のとおり、ＵＵＴが、種々のクラスのプロセスチャンバ２１〜２６および／または測定器具に接続されるように設計されているメインフレーム装置である場合、診断属性は、メインフレーム自体によって、そのメインフレームに付随可能な種々のクラスのプロセスチャンバによって、またそのメインフレームやそのプロセスチャンバに結合可能な種々の器具によって出力された属性を含むことができ、これらのすべては総合的に「データソース装置」と称されている。
【００３９】
属性データベースに記憶されている各レコードは本明細書では「属性レコード」と称されている。図２は、好ましくは属性データベースに含まれているデータフィールドを示している。図示されているフィールドの左から右への順序は任意である。すなわちフィールドは、任意の物理的または一時的順序で各データベースレコード内に記憶可能である。
【００４０】
図２に示されている実施形態において、各属性レコードは各フィールドを含む。属性レコードにおける冗長データのエントリを削減するために複数の関連データベーステーブルを使用する代替実施形態は、「データベース正規化」という見出しの後に、以下説明する。
【００４１】
「ＵＵＴクラス」フィールド
各属性レコードの「ＵＵＴクラス」フィールドは、レコードの残りのフィールドが関連するクラスの機器を識別する。属性データベースを使用して、多数の異なるモデルのＵＵＴについての情報を記憶することができ、この場合各モデルは種々のバージョンを有することができる。従って、好ましい実施形態において、「ＵＵＴクラス」フィールドは、「モデル」および「バージョン」と呼ばれる２個の下位フィールドを有している。「モデル」フィールドに記憶されている値は個々の機器モデルを識別し、「バージョン」フィールドに記憶されている値は、「モデル」フィールドで特定されている機器モデルの具体的なバージョンを識別する。
【００４２】
属性レコードにおけるフィールドは、単一の値を記憶する単純フィールドか、複数の値を記憶する「複合フィールド」のいずれであってもよい。「複合フィールド」を複数のフィールドと定義し、それを「下位フィールド」または「サブフィールド」と呼び、このそれぞれの値は総合的に、複合フィールドによって表されているパラメータ値を特定する。例えば、先行段落で説明されている「ＵＵＴクラス」フィールドは複合フィールドである。ＵＵＴクラスは、「モデル」サブフィールドにおいて機器モデルを指定することによって、また「バージョン」サブフィールドにおいてそのモデルのバージョンを指定することによって、完全かつ一意に識別される。
【００４３】
下位フィールドはそれ自体が複合フィールドである。つまり、下位フィールドは複数のさらなる下位フィールドを含むことができる。例えば、「バージョン範囲」という見出しの後に説明されているように、「バージョン」フィールドは、「バージョン」フィールドが単一のバージョンではなく一連の機器バージョンを識別できるようにする「バージョン、最初」および「バージョン、最終」を含むことができる。
【００４４】
「データベース正規化」という見出しの後で説明されているように、所与の複合フィールドのサブフィールドは異なる関連データベーステーブルに記憶可能であるが、依然として、本特許出願のために同じ複合フィールドのサブフィールドが考慮されている。
【００４５】
「属性」フィールド
「属性」フィールドは、そのＩＤおよび他の特性（例えば物理的単位および変換係数）が属性レコードの残りのフィールドによって説明されている診断属性の名称を含有している。上記のとおり、ＵＵＴの診断属性は、ＵＵＴおよびＵＵＴに直接または間接に付随している全チャンバ、測定器具および他の装置の全センサ測定結果および動作条件を含む。属性データベースは、「ＵＵＴクラス」フィールドで識別されているクラスのＵＵＴが出力可能な診断属性ごとに別個の属性レコードを含む。
【００４６】
図１に示されている複数のチャンバ２１〜２６に接続するように設計されているメインフレーム１２である複数のクラスのＵＵＴについて、所与の属性値がいずれのチャンバに適用するかを識別することが重要である。通常、メインフレームは、異なるチャンバの同一属性を区別するために異なるＩＤを割り当てる。
【００４７】
チャンバに関する属性は、属性名称とチャンバ位置の両方が特定されている場合にのみ、一意に特定されるので、チャンバ関連属性の属性レコードにおける「属性」フィールドは、図２に示されているような２個の下位フィールド、「属性名称」フィールドと「チャンバ位置」フィールドとを含むべきである。チャンバ関連属性ごとに、データベースは、メインフレームのチャンバ位置ごとの別個のレコードを含むべきである。これによって属性データベースは、メインフレームによって各チャンバ位置と関連した各属性に割り当てられている一意のＩＤを（各レコードの「ＩＤ」フィールドに）記憶することができる。
【００４８】
反対に、「属性」フィールドで特定されている属性が、メインフレームに接続されているチャンバのうちの１つではなくメインフレーム自体に関している場合、「チャンバ位置」フィールドは関連性がなく、「チャンバ位置」フィールドは省略可能であり、あるいはフィールドの値はゼロまたは空に設定されてもよい。
【００４９】
例えば、１モデルのメインフレーム１２は、図１に示されているように最大６個のプロセスチャンバに付随していてもよい。チャンバごとの測定済み属性の１つはチャンバ内の圧力であるとする。その場合、「圧力」という属性名称は単一の診断属性を完全かつ一意には識別しない。代わりに、「圧力」属性の完全な識別は、「チャンバ１の圧力」、「チャンバ２の圧力」などのチャンバ位置を特定しなければならない。概して、メインフレームは、それぞれの６個のチャンバの圧力測定結果を検索するために、診断装置によって使用される６個の明確なＩＤを割り当てる。これらのＩＤは６個の明確なデータベースレコードの形態でデータベースに記憶され、本明細書では各レコードは「属性名称」フィールドに記憶されている「圧力」という同一名称を有しているが、「チャンバ位置」フィールドの値１〜６のうちの明確な１つを有しており、「ＩＤ」フィールドの６個のＩＤのうちの対応する１つを有しているのである。
【００５０】
多くの場合、属性名称とチャンバ位置は、属性を検索するのに必要なＩＤを一意に判断するには十分ではないために、「属性」フィールドは１つ以上の追加サブフィールドを必要としている。図２は、１つの可能な追加サブフィールドは「チャンバモデル」であることを示している。「従来のＵＵＴおよび診断装置」という見出しの後に説明されているように、図１に示されているメインフレームＵＵＴ１２は、プラズマＣＶＤチャンバ２１〜２３、加熱チャンバ２４およびプラズマエッチングチャンバ２５、２６などの複数の異なるタイプのチャンバに接続可能である。さらに、所与のチャンバタイプは概して複数の異なるモデルで使用可能である。例えば、Ａｐｐｌｉｅｄ  Ｍａｔｅｒｉａｌｓは、「ＭｘＰ」、「ＭｘＰ＋」および「Ｓｕｐｅｒ−ｅ」というモデル名で異なるモデルのプラズマエッチングチャンバを市販している。「チャンバモデル」フィールドは、「ＭｘＰ  Ｅｔｃｈ」などのチャンバタイプおよびモデルを識別するために十分な情報を記憶すべきである。
【００５１】
一部のクラスの診断属性はこれらの異なるチャンバタイプおよびモデルによって共有されているが、異なるチャンバモデルは、同じＩＤを所与の診断属性にめったに割り当てない。例えば、陰極温度を検索するのに必要なＩＤは、チャンバ位置６でメインフレームに付随するモデルＭｘＰの「１２３」および同じ位置でモデル「Ｓｕｐｅｒ−ｅ」チャンバの「４５６」であってもよい。従って、本例において、３個のサブフィールド、「属性名称」、「チャンバ位置」および「チャンバモデル」は、「位置６でのＭｘＰエッチングチャンバの陰極温度」などの診断属性を完全かつ一意に識別するのに必要とされており、これは、３個のそれぞれのフィールドに記憶されている値がそれぞれ「陰極温度」、「６」および「ＭｘＰ  Ｅｔｃｈ」である属性レコードによって表される。
【００５２】
図２は、「チャンバモデル」サブフィールドを「チャンバモデルまたは構成」とラベリングして、ＵＵＴやチャンバの構成を表す１つ以上の他のパラメータがこのフィールドのチャンバモデルと置換可能であることを記している。
【００５３】
イオン注入マシーンなどの単一の永続プロセスチャンバのみを有している複数のクラスのＵＵＴについて、「属性」フィールドはサブフィールドを含む必要なはい。その場合、「属性」フィールドは、上記の「属性名称」サブフィールドと同じ機能を実行しなければならない、すなわち、その特性が属性レコードの残りのフィールドによって記述されている診断属性の名称または記述を記憶しなければならない。
【００５４】
各々の属性レコードは任意に、図２に示されているような「読み取り／書き込み」フィールドをさらに含むことができる。このフィールドを使用して、「属性」フィールドで特定されている診断属性が（１）診断装置によって読み取り（つまり検索または収集）可能であるが修正不可能である、（２）読み取りおよび修正可能である、あるいは（３）修正可能であるが読み取り不可能である、のいずれであるかを表示する論理「フラグ」を記憶することができる。
【００５５】
「インタフェース＆プロトコル」フィールド
図２に示されているように、各属性レコードは好ましくは「インタフェース＆プロトコル」フィールドを含む。異なる外部インタフェースが異なる診断属性を出力するように、ＵＵＴが１つ以上の外部通信インタフェース１８を有している場合、「インタフェース＆プロトコル」フィールドに記憶されている値は、ＵＵＴのいずれの物理インタフェースが「属性」フィールドで特定されている診断属性を出力するのかを識別するべきである。同様に、ＵＵＴが、ＵＵＴのものとは別個の外部インタフェースを具備するチャンバや器具を有することができる場合、「インタフェース＆プロトコル」フィールドは、これらのインタフェースのうちのいずれが、「属性」フィールドで特定されている属性を出力可能であるかを識別する。
【００５６】
「インタフェース＆プロトコル」フィールドは好ましくは、アナログまたはディジタルハードウェアプロトコルと、任意であるが、ＵＵＴが特定されたインタフェースにて属性データを出力する低レベル通信プロトコルとを識別するべきである。異なる通信インタフェースで用いられてもよいハードウェアプロトコルの例はＲＳ−２３２とイーサネットである。異なるＵＵＴが用いてもよい通信プロトコルの例はＳＥＣＳ、ＧＥＭおよびＩＰである。「インタフェース＆プロトコル」フィールドを使用して、ＤＢ−９、ＤＢ−２５またはＲＪ−４５などのインタフェースに使用されている電気コネクタのタイプを特定することも可能である。この段落で述べられているすべてのハードウェアおよび通信プロトコルは公知の標準である。
【００５７】
データベースに記録されている全ＵＵＴクラスが、属性データを出力するために同じ通信プロトコルを用いており、かつＵＵＴクラスのいずれも、属性データを出力するために１つ以上の外部通信インタフェースを必要としない場合に、「インタフェース＆プロトコル」フィールドは属性データベースから省略されてもよい。
【００５８】
インタフェースおよびプロトコルが図２の単一のフィールドによって表されているのは、所与のインタフェースで使用されている通信プロトコルは概して、そのインタフェースで出力されている全診断属性に対して同一であるからである。つまり、ＵＵＴや他のデータソースは、同一のインタフェースを介して異なる診断属性を出力するために異なるプロトコルを用いないのである。従って、インタフェースおよびプロトコルが、別個のフィールドにおいて相互に独立して特定されるのを許容する必要性はない。
【００５９】
しかしながら、データベース構造の実際のプログラミングにおいて、「インタフェース＆プロトコル」フィールドを、先行段落で論じられているハードウェアおよび通信プロトコルのレベルごとに別個のサブフィールドに分割することはより便利であろう。関連データベースを設計する際の共通の実用性は、これらのプロトコルレベルの各々について別個のフィールドを有する「インタフェース＆プロトコル」テーブルを定義することである。「インタフェース＆プロトコル」テーブルは、「属性」テーブルの「インタフェース＆プロトコル」フィールドを介して、図２に示されている「属性」テーブルに「関して」いるべきである。
【００６０】
「ＩＤ」フィールド
「ＩＤ」フィールドは、診断装置が、属性レコードの「ＵＵＴクラス」フィールドによって識別されているクラスのＵＵＴ機器から、「属性」フィールドによって識別されている診断属性の値を検索する（すなわち読み取る、または収集する）ことができるＩＤを含有している。すでに説明されているように、ＵＵＴは従来、所与の外部通信インタフェースから出力可能な各診断属性に一意のＩＤを割り当てている。
【００６１】
ＩＤの意味は、その診断属性を出力するためにＵＵＴによって用いられている通信インタフェースおよびプロトコルのタイプによる。論じられているように、通信プロトコルは好ましくは「インタフェース＆プロトコル」フィールドで特定されている。
【００６２】
「インタフェース＆プロトコル」フィールドが異なる属性データを持つ複数の信号線を具備するアナログインタフェースを特定する場合、「ＩＤ」フィールドはいずれの信号線（例えば電気コネクタのいずれのピン）が特定された属性を持っているかを識別するべきである。
【００６３】
「インタフェース＆プロトコル」フィールドがコマンド駆動通信プロトコルを使用するディジタルインタフェースを特定する場合、「ＩＤ」フィールドは、「属性」フィールドで特定されている属性を検索するために、診断装置からＵＵＴに送られている「読み取り」コマンドに含まれているに違いない論理または物理アドレスを特定するべきである。
【００６４】
「インタフェース＆プロトコル」フィールドが連続ストリーミング通信プロトコルを使用するディジタルインタフェースを特定する場合、「ＩＤ」フィールドは、ＵＵＴによって周期的に出力されたデータの「フレーム」内の特定された属性データの位置を識別する属性データ、あるいは論理アドレスまたはオフセットを識別する、ＵＵＴによって送信された論理または物理アドレスを特定するべきである。
【００６５】
ハードウェア実現
説明されているように、ＵＵＴ１２は、それを介して属性データを出力する少なくとも１つの外部通信インタフェース１４を有している。診断装置１０は、ＵＵＴの外部通信インタフェース１４と互換性があり、かつこれに接続されている通信インタフェース１８を有しているべきある。診断装置は、異なるクラスのＵＵＴで異なるタイプのインタフェースへの接続を許容する多数の異なるタイプの通信インタフェースを有することができる。
【００６６】
ＵＵＴ１２が従来の半導体製作ツールやメインフレームである場合、その外部通信インタフェース１４は概して既知のＲＳ−２３２シリアル通信標準に準拠しているディジタルインタフェースであり、また半導体産業において広く採用されている公知の「ＳＥＣＳ」通信プロトコルに特定されているコマンドに応答してデータを転送する。このような半導体メインフレームを監視するための診断装置１０は従来、既知のＷｉｎｄｏｗｓ、ＭａｃｉｎｔｏｓｈまたはＬｉｎｕｘオペレーティングシステムを稼動させる汎用「ＰＣ」コンピュータ６２を含むことができる。あるいは、診断装置１０は、マサチューセッツ州アンドーバー（Ａｎｄｏｖｅｒ，Ｍａｓｓａｃｈｕｓｅｔｔｓ）の企業ＭＫＳ  Ｉｎｓｔｒｕｍｅｎｔｓから販売されている「Ｂｌｕｅ  Ｂｏｘ」モデルコンピュータなどの半導体製作ツールを監視することを具体的に目的としているコンピュータ６２を含むことができる。いずれのタイプのコンピュータ６２も一般に、従来のシリアルケーブルを介してＵＵＴのＲＳ−２３２ポートに接続可能なＲＳ−２３２シリアルポート１８を有している。従来のデータ収集および分析ソフトウェアがコンピュータにインストール可能である。このようなソフトウェアは、所望の属性データをＵＵＴから検索するために、ＳＥＣＳプロトコルなどの、ＵＵＴによって使用されている通信プロトコルに従った診断装置の通信インタフェースを介してデータ転送をコントロールすることができる。ソフトウェアはまた検索された属性データをサービス要員に提示して、そのデータを従来のコンピュータ記憶デバイス６０に記憶または「ログ」して、検索された属性データにおいて一定の条件の発生を検出すると警告をシグナリングして、データの統計的分析を実行することができる。例えば、これらの性能を具備するソフトウェアはＭＫＳ  Ｉｎｓｔｒｕｍｅｎｔｓおよびカリフォルニア州サンカルロス（Ｓａｎ  Ｃａｒｌｏｓ，Ｃａｌｉｆｏｒｎｉａ）の企業Ｂｒｏｏｋｓｉｄｅ  Ｓｏｆｔｗａｒｅから市販されている。
【００６７】
動作において、人的ユーザは診断装置に、ＵＵＴから一定の属性データを検索することを命令する。命令は、マニュアルタイプのコマンド、プッシュボタン、または複数の属性がデータ収集プランに従って検索されるべきシーケンスを特定する診断装置にユーザによって記憶されているコンピュータプログラムの形態であってもよい。これらはすべて、上記の市販されているデータ収集ソフトウェアおよびコンピュータハードウェアの従来の特徴である。
【００６８】
我々の発明を実現するために、上記の属性データベースは、プログラマブルコンピュータ６２に基づいている上記の従来の診断装置１０のうちの１つに付加されることが可能である。
【００６９】
属性データベースレコードは、１つ以上のコンピュータハードディスクドライブなどの任意の従来のデータ記憶デバイス６０に記憶されることが可能である。本特許明細書に説明されているレコードおよびフィールドの形態の属性データベースの論理構造は、従来のコンピュータ６２にインストールされている任意の従来のデータベース管理システム（ＤＢＭＳ）ソフトウェアの簡単なプログラミングによって実現可能である。ＤＢＭＳソフトウェアは、Ｍｉｃｒｏｓｏｆｔ、ＩＢＭおよびＯｒａｃｌｅなどの種々のソフトウェア企業から市販されている。オープンソースＳＱＬ  ＤＢＭＳソフトウェアはまた一般的に入手可能である。当然、データ記憶デバイスは、任意の従来のデータインタフェースによってコンピュータに接続可能である。
【００７０】
その属性データベースおよびＤＢＭＳソフトウェアは、図１に示されている診断装置１０内のデータ記憶デバイス６０およびコンピュータ６２にインストール可能である。ＤＢＭＳソフトウェアと、上記のデータ収集および分析ソフトウェアの両方とも同一のコンピュータ６２にインストールされて同時に稼動可能である。
【００７１】
より好ましくは、図５に示されているように、属性データベースおよびＤＢＭＳソフトウェアは離れた場所でデータ記憶デバイス６４とサーバコンピュータ６６とにインストール可能である。診断装置１０は、ローカルエリアネットワーク、ワイドエリアネットワーク、または電話を介するポイントトゥポイントリンクなどの従来のデータ通信リンク６８を介してサーバコンピュータ６６に接続することができる。サーバコンピュータ６６にインストールされているＤＢＭＳソフトウェアは好ましくは、マルチユーザサーバ性能を有しているため、異なる場所の多数の診断装置１０がデータベースに同時にアクセス可能である。
【００７２】
例えば、属性データベースがインストールされているデータ記憶デバイス６４は、時折容易に更新されて、新たなモデルかつ新たなバージョンのＵＵＴを含むことができる中央オフィスに配置されてもよい。携帯診断装置１０は、世界中のカスタマサイトに搬送されて、カスタマ所有のＵＵＴにサービス提供することができる。各診断装置は通信リンク６８を介してデータベースにアクセス可能である。
【００７３】
属性データベースが、図５に示されているように離れて配置されている６４とサーバコンピュータ６６とにインストールされている場合、各診断装置１０は、従来のデータベースのクライアントソフトウェアがインストールされているコンピュータ６２を含んでいなければならない。このようなソフトウェアは従来、診断装置が、例えば属性のＩＤや他の特性を判断するためにデータベースレコードを検索する必要がある場合には常に、通信リンク６８を介してサーバコンピュータ６６にリクエストを送ることができる。各診断装置１０内のコンピュータ６２はまた、属性データを検索するＵＵＴと通信するための上記の従来のソフトウェアを含むべきである。
【００７４】
動作
診断装置を使用して所与のクラス（モデルおよびバージョン）のＵＵＴから属性データを検索する前に、そのクラスのＵＵＴの診断属性を特徴付ける上記の属性レコード（図２）は属性データベースに記憶されているべきである。概して、ＵＵＴの製造者は、ＵＵＴが送信可能な各診断属性のＩＤおよび他の特性を供給する。従って、診断装置のユーザは、上記のデータベース構造に従って、ＵＵＴ製造者からこのような属性特性を取得して、情報を属性データベースに記憶することができる。好ましくは、ＵＵＴの製造者は情報を直接データベースに記憶して（つまりデータベースを作ったり、占めたりして）、ユーザが製造者から情報を取得して、それをデータベースに記憶するためにリフォーマットする必要性を回避することができる。
【００７５】
図６は、診断装置１０が上記属性データベースを使用してＵＵＴから属性データを検索するステップを示しているフローチャートである。これらのステップは好ましくは、診断装置内のコンピュータ６２の簡単なプログラミングによって実現される。以下のステップ６０１〜６０７を実現するソフトウェアは本明細書では、属性ルックアップソフトウェアと称されている。属性ルックアップソフトウェアは好ましくは、「ハードウェア実現」という見出しの後に説明されている従来のデータ収集および分析ソフトウェアを稼動させる診断装置１０内の同一のコンピュータ６２にインストールされている。このソフトウェアのすべてはコンピュータ上で同時に稼動することができる。
【００７６】
ステップ６０１：診断装置は、いずれのクラス（モデルおよびバージョン）のＵＵＴに接続されているかを識別しなければならない。従来のＵＵＴには、診断装置によってＵＵＴのディジタル通信インタフェース１４に送られたコマンドに応答してそれ自身を識別することができるものもある。このような性能を欠いたＵＵＴでは、診断装置を使用する人は、例えばキーボード入力を介して、ＵＵＴを識別して、この情報を診断装置に提供することを担っている。「属性データベース」および「ＵＵＴクラスフィールド」と題された先行セクションで説明されているように、１クラスのＵＵＴを一意に識別するのに必要な情報はモデル指定を含んでおり、バージョン指定（例えばバージョン番号やバージョン日付）は、異なるバージョンが異なる属性特性を有している場合には、そのクラスのＵＵＴを一意に識別するのに必要である。
【００７７】
ステップ６０２：任意であるが、属性データベースが遠隔サーバ６６に記憶されている場合には、診断装置はサーバの記憶デバイス６４からそのローカル記憶デバイス６０に、識別されたクラスのＵＵＴの全属性レコード、つまりその「ＵＵＴクラス」フィールドがステップ６０１で識別されたクラスのＵＵＴに一致する全属性レコードのコピーを転送することができる。通信リンクはこのステップ６０２でのみ必要であるから、この任意のステップ６０２は、診断装置の後続の動作時に遠隔サーバとの連続通信リンク６８を維持する必要性を排除する。このステップは、サーバコンピュータ６６上のＤＢＭＳサーバソフトウェアにクエリーを送る、ローカルコンピュータ６２上のデータベースクライアントソフトウェアによって遂行される。
【００７８】
ステップ６０３：診断装置は、サービス要員がＵＵＴから検索するために選択する１つ以上の属性を識別しなければならない。選択された属性はキーボード入力によってマニュアルで識別されてもよく、または、サービス要員が診断装置のコンピュータにすでに記憶したデータ収集プランにおいて特定されてもよい。このステップは、ステップ６０１の前、後あるいはこれと同時に実行されてもよい。マルチチャンバＵＵＴに付随しているチャンバと関連した属性について、属性の識別は、「属性フィールド」と題された先行セクションで説明されているように、チャンバモデル、チャンバ位置および他の適用可能なチャンバ構成パラメータを識別することを含むべきである。
【００７９】
ステップ６０４：ステップ６０３で選択された属性ごとに、診断装置は属性データベースにクエリーを行い、ステップ６０１で識別されたＵＵＴクラスと、選択された属性の両方に対応する属性レコードを検索する。任意のステップ６０２が実行された場合、診断装置は、ステップ６０２でそのローカル記憶デバイスに転送されている属性レコードを検索して、選択した属性とその「属性」フィールドが一致する属性レコードを見つけることができる。あるいは、ローカルコンピュータ６２上の従来のデータベースクライアントソフトウェアは、サーバコンピュータ６６上のＤＢＭＳサーバソフトウェアにクエリーを送って、その「ＵＵＴクラス」フィールドがステップ６０１で識別されたＵＵＴクラスと一致し、かつその「属性」フィールドが選択された属性と一致する属性レコードを検索しなければならない。
【００８０】
ステップ６０５：ステップ６０４で検索された属性レコードごとに、診断装置は、レコードの「ＩＤ」フィールドからその属性のＩＤを読み取る。このようなフィールドが属性レコードに含まれている場合、診断装置はまた、レコードの「インタフェース＆プロトコル」フィールドからインタフェースおよびプロトコル情報を読み取り、そしてレコードの「読み取り／書き込み」フィールドから読み取り／書き込みフラグを読み取る。
【００８１】
ステップ６０６：次に診断装置は、ステップ６０５からのＩＤ、インタフェース情報およびプロトコル情報を使用してＵＵＴの外部通信インタフェースから実際の属性データを検索する。ＵＵＴおよびその関連データソースが総合的に１つ以上の外部通信インタフェースを有している場合、インタフェース情報は、いずれのインタフェースから診断装置がこのステップにおいて属性を検索するべきであるかを特定する。プロトコル情報はＵＵＴが必要としている検索方法を特定する。通常、「従来のＵＵＴおよび診断装置」および「インタフェース＆プロトコルフィールド」と題された先行セクションで説明されている方法のうちの１つである。
【００８２】
例えば、ＵＵＴ１２が、その属性データを出力するためにコマンド駆動プロトコルを用いる場合、診断装置はＵＵＴに、ＩＤを特定する「読み取り」コマンドを送る。別の例として、ＵＵＴが上記のように連続ストリーミングプロトコルで属性データを送信する場合、診断装置１０は所望の属性のＩＤを使用して、データストリームの属性データをＵＵＴから検索する。あるいは、ＵＵＴが特定された属性をアナログインタフェースにて出力すると、診断装置は、「インタフェース＆プロトコル」フィールドで特定されたインタフェースからアナログ信号を単に読み取る。インタフェースが複数の信号線を有している場合、「ＩＤ」フィールドは、インタフェースのいずれの信号線から診断装置がアナログ信号を読み取るのかを特定しなければならない。
【００８３】
好ましくは、診断装置のコンピュータ６２は、「ハードウェア実現」という見出しの後に説明されている従来のデータ収集ソフトウェアを含む。その場合、ステップ６０６で、属性ルックアップソフトウェアは好ましくは、ステップ６０５で得られたＩＤ、インタフェース情報およびプロトコル情報をデータ収集ソフトウェアにパスし、これは、特定された通信プロトコルを用いてＵＵＴから属性データを検索する。
【００８４】
ステップ６０７：属性レコードが「変換」フィールドや「スケール係数」フィールド値を含む場合、属性レコードで特定された変換やスケール係数を適用する。属性レコードが「物理的単位」フィールド値を含む場合、属性データとともにその値を記憶する。これらのフィールドについて「物理的単位への変換」という見出しの後に説明する。
【００８５】
物理的単位への変換
各データベースレコードはさらに、１つ以上の下位フィールドを含有する「変換」フィールドを含むことができ、これらの各々は、ＵＵＴによって出力されたアナログまたはディジタル電気信号を、「属性」フィールドによって識別された属性値の物理的単位の測定結果に変換するために、スケール係数などの変換パラメータを記憶している。「変換」フィールドの追加下位フィールドは、「ワット」、「摂氏温度」、「トール（ｔｏｒｒ）」または「ｓｃｃｍ」などの、このような物理的単位の測定結果の単位を特定することができる。
【００８６】
本発明の譲渡人によって市販されている多数のモデルのメインフレームにおいて、メインフレームによって出力された属性データは、その可能な値がゼロ〜２Ｎ−１に及ぶＮビットのバイナリ数であり、この場合ゼロおよび２Ｎ−１のバイナリ値はそれぞれ属性の最小物理値と最大物理値を表している。このような属性について、「変換」フィールドは好ましくは３個の下位フィールドからなっている。つまり「最小」、「最大」および「単位」である。「最小」および「最大」フィールドに記憶されている数値は、それぞれゼロおよび２Ｎ−１のバイナリ値を有する属性データによって表されている物理属性値である。「単位」フィールドに記憶されている値は、このような物理属性値が表されている物理的単位を指定している。
【００８７】
例えば、メインフレームによって出力された属性のうちの１つが第３のチャンバのサセプタの温度であり、またその範囲の温度測定結果は５０℃〜５５０℃であるとする。従って、メインフレームはゼロ〜２Ｎ−１の範囲のバイナリ値を出力して、５０℃〜５５０℃の範囲の温度を表さなければならない。その場合、「５０」および「５５０」という値は、第３のチャンバのサセプタの温度に対するデータベースレコードの「最小」および「最大」フィールドにそれぞれ記憶されるべきであり、また「摂氏温度」という値はそのレコードの「単位」フィールドに記憶されるべきである。
【００８８】
バージョン範囲
「属性データベース」および「ＵＵＴクラスフィールド」と題された先行セクションで説明されているように、各データベースレコードの「ＵＵＴクラス」フィールドは、レコードの残りのフィールドが関連しているクラスの機器を識別する。概して、そのクラスのＵＵＴは、機器モデル、機器バージョンまたは両者の組み合わせによって定義可能である。つまり、複数のクラスのＵＵＴは種々の機器モデルを含んでいてもよく、各モデルのＵＵＴは、その属性の仕様が異なる種々のバージョンまたは世代によって生成可能である。データベースが、種々のモデルのＵＵＴならびに各モデルの種々のバージョンまたは世代間の差異を記録することができるように、各データベースレコードの「ＵＵＴクラス」フィールドは、「モデル」下位フィールドおよび「バージョン」下位フィールドを含む組み合わせフィールドである。言い換えると、各モデルのメインフレーム機器の各バージョンは明確なＵＵＴクラスについて考慮されている。
【００８９】
バージョンまたは世代を識別するための、「バージョン」フィールドに記憶されている値は、例えばバージョン番号やバージョン日付であってもよい。所与のモデルのＵＵＴのバージョンは、その物理的特徴またはそのオペレーティングソフトウェアのいずれかにおいて相互に異なっていてもよい。バージョンが、ＵＵＴがその外部通信インタフェースを介していずれの診断属性を出力するか、または送信された属性の特性（例えばそれぞれのＩＤや、１つ以上の属性に関連する変換係数）において相互に異なっている場合、これらの差異をトラックするために本発明の属性データベースを用いることは有用である。
【００９０】
本発明の属性データベースは、診断装置が単一のモデルのＵＵＴ機器に接続されているだけの場合でもバージョン間の差異を集計することが有用である。その場合、「ＵＵＴクラス」フィールドの「モデル」サブフィールドの必要性はない。言い換えると、「ＵＵＴクラス」フィールドは「バージョン」フィールドであるにすぎない。
【００９１】
ＵＵＴクラスがモデルおよびバージョンの両方によって定義されているより一般的なケースに戻ると、一実施形態において、属性データベースはＵＵＴクラスごとに明確なセットのレコードを含有しており、また所与のＵＵＴクラスに対する該セットのレコードは、ＵＵＴのモデルおよびバージョンによって出力可能な診断属性ごとの明確なレコードを含む。例えば、所与のモデルのメインフレーム機器がその履歴の間に２０個のバージョンのソフトウェアおよび／またはハードウェア変化を経験し、またそのモデルの各バージョンが３０個の属性を有している場合、データベースは、そのモデルの全バージョンの属性の仕様を記憶するために６００個のレコード（２０個のバージョン×バージョンあたり３０個の属性）を必要とする。
【００９２】
属性データベースのより好ましい実施形態は、各属性レコードの「バージョン」フィールドが単一のバージョンだけではなく一連のバージョンを表せるようにすることによって必要なレコード数を削減する。具体的には、所与の診断属性のインタフェース仕様および他の特性は所与のモデルのＵＵＴの一連のバージョンについて同一のままであり、バージョンごとに明確なレコードを記憶するのではなく、単一のレコードがデータベースに記憶されて、その範囲内の全バージョンの診断属性を特徴付ける。
【００９３】
図３は、各データベースレコードの「バージョン」フィールドが、「バージョン、最初」および「バージョン、最終」と呼ばれ、その内容はレコードの残りのフィールドが適用する「モデル」フィールドで識別されているＵＵＴモデルの最初と最終のバージョンをそれぞれ識別する２個の下位フィールドを含む複合フィールドであるこの技術の実現について示している。本発明のこの実施形態において、「ＵＵＴクラス」を具体的なモデルのＵＵＴの一連の１つ以上のバージョンと定義する。
【００９４】
例えば、「アルファ」と呼ばれるメインフレームモデルがその履歴の間に２０個の改訂を経験しているとする。アルファメインフレームのバージョン１〜７において、「チャンバ１の圧力」という属性が論理ポート３３に割り当てられて、バージョン８〜１６においてこの属性は新たな論理ポート４４に割り当てられて、またバージョン１７〜２０において、この属性が再び論理ポート３３に割り当てられたとする。図３に示されているように、これらのバージョンは２０個ではなく３個のデータベースレコードによって表されることが可能である。
【００９５】
図４は、「バージョン」フィールドが隣接していない複数のバージョンを特定可能であることによって、最初のバージョンと最終のバージョンによって結ばれている範囲として定義不可能な代替実施形態を示している。この実施形態において、「バージョン」フィールドは、レコードが適用するＵＵＴモデルのバージョンを各々が識別する多数の下位フィールドを含むことができ、下位フィールドは総合的に１セットのＵＵＴバージョンを識別する。先行段落の例において、アルファの「チャンバ１の圧力」という属性はデータベースの２個のレコードだけで表すことができる。つまり、図４に示されているように、バージョン１〜７および１８〜２０のレコードと、バージョン８〜１７の第２のレコードである。第１のデータベースレコードは、それぞれの値「１」、「７」、「１７」および「２０」が記憶されている「１−バージョン、最初」、「１−バージョン、最終」、「２−バージョン、最初」および「２−バージョン、最終」と呼ばれる４個の下位フィールドからなる「バージョン」フィールドを有している。
【００９６】
バージョンは総合的にバージョン番号によって識別されるが、非数値名称もまた異なるバージョンを識別するために使用可能である。
【００９７】
あるいは、バージョンはバージョン番号ではなく日付によって識別可能である。例えば、図２に示されている実施形態において、属性データレコードの「バージョン」フィールドは、属性データレコードが適用するＵＵＴクラスの、バージョン番号ではなく関連日付を記憶することができる。同様に、図３に示されている実施形態において、「バージョン、最初」および「バージョン、最終」フィールドは、レコードが適用するＵＵＴクラスの最初の生産日と最終の生産日とを記憶して、属性データレコードが、特定された最初と最終の生産日間に生成されたそのＵＵＴクラスの全機器に適用することを意味する。
【００９８】
データベース正規化
広く上述した図２は、属性データベースのレコードにおけるフィールドについて描いている。同一のデータベース構造が、テーブル形態で図７に描かれている。図７および８に示されているデータベーステーブルにおいて、フィールド名称に対する表記「Ａ：Ｂ」は、「Ａ」と名づけられた複合フィールドのうちの「Ｂ」と名づけられたサブフィールドを表している。
【００９９】
図８は、「属性」テーブルおよび「属性名称＆チャンバ構成」テーブルと呼ばれる２つのテーブルに分割することによってデータベースが少なくとも部分的に正規化可能である様子を示している。データベースを正規化するために、その値が相互に独立してほとんどまたはまったく変化しないフィールドがテーブルにグルーピングされている。正規化されたデータベースは、メインデータベーステーブルである属性テーブルのレコードにおいて冗長フィールドを排除することによって、記憶要件を削減する。
【０１００】
各データベーステーブルにおいて、列挙されている第１のフィールドはテーブルのキーフィールドであり、これは、テーブルの各レコードは異なる値をキーフィールドに記憶していることを意味している。属性テーブルにおいて、各属性は異なるＩＤを有しているために、ＩＤがキーフィールドである。
【０１０１】
メインフレームとは対照的に、プロセスチャンバの動作条件や測定結果を表す診断属性はたいてい、チャンバ内、またはチャンバに付随する測定器具内のアナログ／ディジタルコンバータを使用してアナログ測定結果からディジタル属性データに変換される。その結果、変換パラメータ（単位およびスケール係数）ならびに、パラメータが読み取り専用であるか、読み取り／書き込み用であるかについてはたいてい、チャンバモデルおよびチャンバ構成によって全体的に判断され、また、チャンバが接続されているＵＵＴのモデルおよびバージョンとは無関係である。論理的には、変換パラメータはまた、所与のプロセスチャンバが搭載されているメインフレームのチャンバ位置とは無関係である。従って、変換パラメータおよび読み取り／書き込みフラグを表すデータベースフィールドは属性テーブルから「チャイルド」テーブルに移動可能である。
【０１０２】
変換パラメータおよび読み取り／書き込みフラグに加えて、「チャイルド」テーブルに含まれている追加フィールドは、変換パラメータおよび読み取り／書き込みフラグの値を一意に判断するのに必要なフィールドである。これらの追加フィールドは、先行段落で説明されている理由から、「属性：名称」フィールドおよび「属性：チャンバモデルまたは構成」フィールドである。これら２つのフィールドは総合的にデータベーステーブルのキーフィールドを定義する。従って、チャイルドフィールドは「属性名称＆チャンバ構成」テーブルと名付けられている。テーブルのレコードごとにキーフィールドに記憶されている値は任意のインデックス番号であってもよく、あるいはそのレコードの「属性：名称」フィールドおよび「属性：チャンバモデルまたは構成」フィールドの値を連結させることによって形成されてもよい。
【０１０３】
「属性名称＆チャンバ構成」テーブルを作成することの利点は、「属性：名称」、「属性：チャンバモデルまたは構成」、「読み取り／書き込み」、「変換：単位」、「変換：スケール係数：最小」および「変換：スケール係数：最大」に対してすでに必要とされている６個のフィールドに代わって、「属性名称＆チャンバ構成キー」という単一のフィールドを含んでさえいればよいという点である。これによって、データベースに必要な記憶を削減する。
【図面の簡単な説明】
【０１０４】
【図１】６個のプロセスチャンバを有する半導体製造メインフレームである従来のＵＵＴに接続されている本発明の診断装置の概略図である。
【図２】本発明の好ましい実施形態に従った属性データベースの属性レコードにおけるフィールドの概略図である。下位フィールドは、これらが属する複合フィールドの下に描かれている。
【図３】そのＩＤが例示的モデルのＵＵＴの異なるバージョンで変化する例示的属性を表している３個の属性レコードに記憶されている値の概略図である。
【図４】図３の３個のレコードと同じ情報を表すことができる２個の属性レコードの概略図である。
【図５】属性データベースが診断装置から離れているシステムの概略図である。
【図６】属性データベースに記憶されている情報を使用して診断装置がＵＵＴから属性データを検索するステップを示しているフローチャートである。
【図７】図２に示されているフィールドを有する属性データベースを表すデータベーステーブルである。
【図８】２個のテーブルに分割されている、図７のデータベースを示しているデータベーステーブルである。
【符号の説明】
【０１０５】
１０…診断装置、１２…ＵＵＴ、１４…ディジタルインタフェース、１５…アナログ通信インタフェース、１８…通信インタフェース、２１〜２６…プロセスチャンバ、３０…コンピュータプロセッサ（ＣＰＵ）、３１…通信チャネル、３２…データポート、３３…内部データポート、５０…測定器具、５２…追加内部データポート、６０…データ記憶デバイス、６４…データ記憶デバイス、６６…サーバコンピュータ、６８…データ通信リンク
【図１】
2011101023.tif 000003
【図２】
2011101023.tif 000004
【図３】
2011101023.tif 000005
【図４】
2011101023.tif 000006
【図５】
2011101023.tif 000007
【図６】
2011101023.tif 000008
【図７】
2011101023.tif 000009
【図８】
2011101023.tif 000010