JP5341875B2 - レシピおよび部品の制御モジュールならびにその方法 - Google Patents

Description

プラズマ処理の進歩は、半導体産業における成長を容易にした。半導体デバイスを作るために、基板処理を行うためのプロセスモジュールは長い間採用されてきた。

半導体デバイスは、欠陥が生じやすい通常は繊細なデバイスであるので、障害検出、評価項目特定および／またはトラブルシューティング用のデータを収集するために、センサーがプロセスモジュールに付けられる。

例えば、レシピ（製造工程設計書）がプラズマ処理システム中で実行されているという状況を考慮されたい。図１は、いかに、センサーがプロセスモジュールと相互作用することができ、いかに、センサーが、処理および調整の目的でプロセスモジュールを利用することができるかを示した概念図である。単純化した処理環境は、処理チャンバー１００を含むことができ、この処理チャンバー１００はプロセスモジュール１０２に接続され、このプロセスモジュール１０２が、複数のセンサー（１０４、１０６、１０８および１１０）に接続されている。通常、各センサーにより収集されたデータは、プロセスモジュール１０２にアップロード可能である。ある例では、様々なセンサーにより収集されたデータは、ネットワーク経路（例えば、イーサーネットパス１１２）を介してプロセスモジュール１０２に送られることができる。
異なる製造メーカーが、複数のセンサー１０４・１０６・１０８・１１０を製造する可能性がある。したがって、複数のセンサーは、大概、異なる時間領域でデータを収集し、互いに通信することができない可能性がある。

近年、トレンドが、フィードバックタイプの自動プロセス制御へ移行しつつある。したがって、評価項目検出、障害検出およびトラブルシューティングのために、より時機を得たデータが要求される。この結果、処理により多くのデータが必要とされるので、プラズマ処理システムに追加されるセンサーの数が増えている。センサーの数が増えることにより、タスクを行うためのソフトウェアで制御されるプロセスモジュールに、より多くのデータを提供することができるが、センサーとプロセスモジュールとの間で、より多くの量のデータが交換されうることにより、実際に、処理全体に対して資源の損失が生じうる。ある例では、ネットワーク経路が混雑する可能性があるが、これは、センサーが、プロセスモジュールにデータを送るために、別のセンサーと競合するからである。別の例では、基板処理を管理する機能を有するプロセスモジュール１０２は、通常、複数のセンサーから入ってくるデータの大規模な氾濫を取り扱うようには設計されていないので、プロセスモジュール１０２は、プロセスモジュールの主要な機能である基板処理制御に悪影響を与えうるような待ち時間の問題に直面する可能性がある。

さらに、プロセスモジュール１０２は、無限数のセンサーを取り扱う処理能力および／またはメモリ容量を持つことはできない。ある例では、追加の詳細を提供するために、別のセンサーモジュールがプロセスモジュールに付けられる必要がある。しかし、処理力の限界およびメモリ能力により、プロセスモジュール１０２は、別のセンサーを取り扱うことはできない可能性がある。したがって、プロセスモジュール１０２は、その限られた資源を、基板処理管理から追加的なセンサーの取り扱いのために転用する。さらに、待ち時間が問題になり、プロセスモジュールがその資源に対する追加的な負担を取り扱うことができなくなり、最終的には壊れてしまいうる。

複数のセンサーからのデータを保存する以外に、プロセスモジュール１０２は、データを分析するために用いられうる。しかしながら、この分析タスクは、限りある資源を、基板処理を管理するタスクから転用するのみならず、プロセスモジュール１０２が、個々のセンサーにおいて保存できる様々な異なるレシピの部分にアクセスするよう要求しうる。残念ながら、通常、プロセスモジュールは、これらのレシピの異なる部分に対してアクセスを有しておらず、受領したデータの適切な分析を行うことはできない可能性がある。

ある例では、センサー１０４に保存されたレシピの１部分に対して変更が行われた。この変更に適応するために、技術者は、異なるモジュール（例えば、センサー、プロセスモジュールなど）をこの変更に基づいて更新せねばならない可能性がある。この変更が、１つまたは複数のモジュール中に反映されていない可能性があるので、レシピを実行することにより、欠陥デバイスを生成してしまう可能性がある。この問題を決定するためにデータを分析する際には、プロセスモジュール１０２は、レシピ中の変更を認識している必要がありうる。レシピが容易に利用可能になっていなければ、プロセスモジュールは、データの不完全な分析をするか、あるいは、センサーからレシピを取り出さねばならず、その結果、要求するデータにアクセスするために、不必要に処理力を消費せねばならず、これにより、限られたネットワークルートにおいて、不必要なデータ通信量の混雑を引き起こしてしまう。

さらに、センサーにより収集された「不良データ」は、プロセスモジュール１０２の性能にも影響を与えうる。ある例では、センサー１０６は損傷を受け、その結果、「不良データ」を収集した。データがプロセスモジュール１０２にアップロードされると、このデータがプロセスモジュール１０２により利用される可能性があり、その結果、基板処理に悪影響を与え、他のセンサーにさえ悪影響を与えうる。

様々なセンサーからアップロードされうる多量のデータを処理することに加えて、プロセスモジュール１０２は、このデータを統合し、センサー間の相互作用を調整する責任も有する可能性がある。各センサーは、異なるデータ収集基準を有し特有のものでありうる。ある例では、あるセンサー１０４は、５０μ秒毎にデータを収集することができ、一方、センサー１０６は、１００μ秒毎にデータを収集することができる。データ収集タイミングの差がセンサー間で異なるため、センサーは通常互いに通信することができず、交換を容易にするためには、プロセスモジュールを採用せねばならない可能性がある。したがって、プロセスモジュールは、これらの種類の要求を取り扱う知能を持つように要求される可能性がある。

残念ながら、プロセスモジュールは、この要求を常に取り扱うことができるとは限らないが、これは、プロセスモジュールが異なる源からのデータを統合することができないからでありうる。ある例では、センサー１０４・１０６からのデータは、異なる時間間隔で収集される。センサー１０４が、センサー１０６により収集されたデータを利用することができるようデータを統合するために、プロセスモジュール１０２は、この２つのデータセットをうまく調和させるための知能を必要としうる。しかしながら、プロセスモジュール１０２は、このような複雑な操作を取り扱うための処理力を有さない可能性がある。また、この２セットのデータを統合するのは、これらのデータが異なる時間領域で収集された場合には、事実上不可能である。

プロセスモジュール１０２は、そもそも基板処理を管理するために作られた。したがって、プロセスモジュール１０２は、追加的なタスクであるデータ保存、データ処理およびデータ調整などを取り扱うためのメモリ資源または処理力を有さない可能性がある。この結果、プロセスモジュール１０２の処理容量およびメモリ容量は拡張される可能性がある。プロセスモジュール１０２に付けられるセンサーの数が増えるにつれ、プロセスモジュール１０２に支障をきたすが、これは、プロセスモジュールが様々な異なるセンサーの要求に合わせようとする一方で、処理チャンバーを管理しようとするからである。したがって、プロセスモジュールは、その待ち時間が長くなり始めたり、実行環境の変更に迅速に反応できなくなったり、完全に停止する可能性さえある。

本発明は、ある実施形態では、レシピおよび部品の制御モジュール（ＲＡＣＣＭ）に関する。

このＲＡＣＣＭは、複数の部品を備えたプラズマ処理システム中でデータ管理を行うサーバーである。このＲＡＣＣＭは、複数の知的エージェントを有する。これらの複数の知的エージェントの各知的エージェントは、上述の複数の部品のうちの各部品と相互作用するように構成されている。ＲＡＣＣＭは、上述の複数の知的エージェントから処理されたデータを受領するように構成されている調整エージェントも有する。

上述の概要は、本願中に開示された本発明の多くの実施形態のうちの１つに関連するにすぎず、これにより本発明の範囲を限定する意図はない。本発明の範囲は、本願の請求項中で述べられている。本発明のこれらのおよびこれ以外の特徴は、以下に本発明の詳細な説明中でおよび以下の図面に関連して、より詳細に説明される。

本発明を、添付の図面の図中、限定の目的ではなく例示の目的で示すが、図中、同様の参照符号は、同様の部材を示す。

どのようにセンサーが、プロセスモジュールと相互作用することができ、どのようにセンサーが、処理および調整の目的でプロセスモジュールを利用することができるかを示した概念図である。 本発明の１実施形態における、レシピおよび部品の制御モジュール（ＲＡＣＣＭ）の単純化した全般的なアーキテクチャ設計を示す図である。 本発明の１実施形態における、センサーの構成工程を示す単純なフローチャートである。 本発明の１実施形態における、知的エージェントがキャッシュから要約データを生成する工程を示す単純なフローチャートである。 本発明の１実施形態における、知的エージェントが評価項目および／または障害検出データを生成する工程を示す単純化したフローチャートである。 本発明の１実施形態において、調整エージェントがデータ分析を行う工程を示す単純化したフローチャートである。 本発明の１実施形態において、臨時エージェントを介してＲＡＣＣＭの異なる実体間でレシピを分配する工程を示す単純化したフローチャートである。 本発明の１実施形態において、部品を知的エージェントと関連づける工程を示す単純なフローチャートである。

ここで、本発明について、添付の図面に図示したいくつかの実施形態を参照してより詳細に説明する。以下の説明中、多数の特定の詳細を、本発明を完全に理解をしてもらうために述べる。しかしながら、当業者には、本発明は、これらの特定の詳細のいくつかまたは全てなしでも実施できることは明らかである。他の例では、本発明を不必要にあいまいにしないために、周知の処理工程および／または構造は詳細に説明をしない。

方法および技術を含む様々な実施形態を以下で説明する。本発明は、本発明の技術の実施形態を実施するためのコンピュータで読み取り可能な指示が保存されているコンピュータで読み取り可能な媒体を有する製造品をも網羅しうることに留意すべきである。このコンピュータで読み取り可能な媒体は、コンピュータで読み取り可能なコードを保存するためのコンピュータで読み取り可能な媒体であって、例えば、半導体形態、磁性形態、光磁性形態、光学形態または他の形態の媒体を含む。さらに、本発明は、本発明の実施形態を実現するための装置も網羅する。このような装置は、本発明の実施形態に関するタスクを実行するための専用のおよび／またはプログラム可能な回路を含む。このような装置の例には、汎用コンピュータおよび／または適切にプログラムされた専用の演算装置も含まれ、これには、コンピュータないし演算装置と、本発明の実施形態に関する様々なタスク用に適合された専用のないしプログラム可能な回路との組み合わせを含むことができる。

本発明の１態様では、プロセスモジュールは、ある面では、センサー同様に振舞いうると発明者らは認識していた。ある例では、センサーとプロセスモジュールとは双方とも、レシピのパラメータに基づいてデータを収集することができる。したがって、別体の制御モジュールは、従来技術でプロセスモジュールがセンサーのために行っていたタスクを行うために採用されうる。したがって、プロセスモジュールは、プロセス制御というその主要な機能を行うのに集中することができる。

本発明の実施形態によれば、レシピおよび部品の制御モジュール（ＲＡＣＣＭ）が、処理システムに付けられた部品のためにデータ管理および／またはレシピ管理を行うアーキテクチャシステムが提供されている。本願中で説明するように、部品とは、データ収集部材のことである。部品は、センサー、計測ツールおよびプロセスモジュールを含みうるが、これらに限定されることはない。プロセスモジュールは、データの収集時にはセンサーと同様のことを行うので、ＲＡＣＣＭは、データ管理および／またはレシピ管理に関しては、プロセスモジュールとセンサーとを同様に扱いうる。

本明細書では、様々な実装に関して、センサーを例として用いて説明している。しかしながら、本発明は、センサーに限定されるのではなく、計測ツールなどの任意のデータ収集部材も含むことができる。あるいは、説明は例として意味を有するのであって、本発明は、提示された例には限定されない。

本発明の１実施形態において、ＲＡＣＣＭは、ある部品を、別の部品に対して影響を与えることなく、追加、除去または修正可能であるモジュールシステムである。従来技術では、センサーが更新されるたびに、プロセスモジュールは、修正されたセンサーに合わせるために再構成されねばならない可能性がある。したがって、プロセスモジュールが再構成される際に、プロセスモジュールに連結された他のセンサーは悪影響を受ける可能性がある。これは、プロセスモジュールが他のセンサーのためにデータ管理を行うことができなくなる可能性があるからである。従来技術とは異なり、センサーの更新は、他の部品、特にプロセスモジュールに対して悪影響を与えることはない。これとは異なり、他の部品は、起こりうる変更に対して気がつかない可能性がある。

本発明の別の実施形態では、ＲＡＣＣＭは、データ管理および／またはレシピ管理を行うことができる複数のエージェント、例えば、知的エージェント、調整エージェントおよび臨時エージェントを含むことができる。したがって、ＲＡＣＣＭは、この作業負荷を複数のエージェント間で分配することができる。プロセスモジュールがデータ管理タスクの全てとはいわないまでもほとんどのタスクを行っていた従来技術とは異なり、作業負荷を分配することにより、データ管理はより迅速におよびより効率的に行われうる。さらに、ＲＡＣＣＭは、複数のプロセッサを有しうる。したがって、１つのエージェントが、より遅い処理を実行したとしても、他のエージェントが他のプロセッサ上にあるので、この１つのエージェントの実行が他のエージェントのデータ処理には影響を与えることはない。

本発明の別の実施形態では、ＲＡＣＣＭは階層的アーキテクチャシステムであり、この場合、作業負荷はエージェントのレベルに基づいて拡散させることができる。ある例では、ＲＡＣＣＭは複数の知的エージェントを有する。これらの知的エージェントは、最低レベルのエージェントであり、これらの知的エージェントは、直接部品と相互作用して部品を構成しかつ部品からデータを受け取る。これと比較して、調整エージェントは最高レベルである。したがって、調整エージェントは、データ分析を行うために、より低いレベルのエージェントから要約データのみを受領しうる。ある実施形態では、調整エージェントが行う分析は、複合的なシグネチャ（signature）を生成し、これが、プロセスモジュールに指示を与えうる。ＲＡＣＣＭ中に存在するレベルの数は、いかにＲＡＣＣＭがその作業負荷を分担したいかに依存しうるという点に留意されたい。ある例では、知的エージェントへの作業負荷を減らすために、調整エージェントと知的エージェントとの間に別のエージェントのレベルがありうる。

本発明のさらに別に実施形態では、ＲＡＣＣＭは、レシピ管理を行うための臨時エージェントを有しうる。実装によっては、このタスクを行うために１つまたは複数の臨時エージェントが採用されうる。従来技術では、レシピの異なる部分が、様々な場所に、例えば、プロセスモジュールおよびセンサーなどにある可能性があった。したがって、レシピの変更は、通常、様々な異なる場所でレシピを物理的に更新するために複数段階のプロセスを必要とした。残念ながら、１つのモジュールの更新を忘れることで、基板処理に悪影響を与え、欠陥デバイスが生じる結果とさえなりえた。従来技術とは異なり、所望の実体に修正したレシピを拡散するタスクは、レシピに修正を行うためにエディターインタフェースを採用するという単純なタスクである。修正されたレシピは、その後プロセスモジュールに送られ、このプロセスモジュールは、修正されたレシピをさらにＲＡＣＣＭに転送しうる。ＲＡＣＣＭ内では、臨時エージェントが修正されたレシピを受領し、このレシピがいかに分配されうるかを決定するために分析を行うことができる。臨時エージェントを採用することにより、レシピ管理は中央集中化され、１つの実体によって自動的に取り扱われる。

ある実施形態では、臨時エージェントは、どのセンサーがそのパラメータを必要としうるかを決めるために、レシピを分析することができる。臨時エージェントがこの決定を行うと、この臨時エージェントは、レシピの一部を、そのセンサーが関連付けられうる知的エージェントに分配しうる。換言すれば、そのレシピは、知的エージェントに保存され、部品には分配されない。レシピをＲＡＣＣＭ内に保存することにより、ＲＡＣＣＭは、データ分析およびデータ操作を行うために、このレシピに容易にアクセスすることができる。

本発明の１実施形態では、ＲＡＣＣＭは、作業負荷の１部分を部品に対してアンロードすることができる。従来技術では、センサーは、選択的にデータをプロセスモジュールにアップロードすることはできない。従来技術とは異なり、ＲＡＣＣＭは、部品に構成要件を送り、データが更新されうる条件を提供することができる。この構成要件により、部品は、データが構成要件に合っているか否かを決めるために、前処理を行うことができる。したがって、ネットワークは、ＲＡＣＣＭが必要としないデータにより不必要に混雑することはない。

本発明の特徴と利点とは、以下の説明および図面を参照すると、より理解されうるであろう。

図２は、本発明の１実施形態における、レシピおよび部品の制御モジュール（ＲＡＣＣＭ）の単純化した全般的なアーキテクチャ設計を示す図である。ＲＡＣＣＭ環境２００は、プロセスモジュール２０２や、複数のセンサー２０４・２０６・２０８・２１０などの複数の部品を含むことができる。従来技術とは異なり、様々な異なるセンサーが、プロセスモジュール２０２に直接連結されるのではない。これに代えて、様々な異なるセンサーは、ＲＡＣＣＭ２１２に連結される。したがって、データは、プロセスモジュール２０２ではなく、ＲＡＣＣＭ２１２に送られる。

加えて、ある実施形態では、プロセスモジュール２０２も、ＲＡＣＣＭ２１２に連結される。プロセスモジュールが、データの収集、取り扱い、調整および／または処理に責任を持つことができる従来技術とは異なり、ＲＡＣＣＭ環境中のプロセスモジュール２０２は、センサーと同様に振舞い、プロセスモジュール２０２も、ＲＡＣＣＭ２１２にデータをアップロードする。したがって、プロセスモジュールから、データ管理のタスクを外すことにより、プロセスモジュールは、その主要なタスクであるプロセス制御に集中することができ、生じうる問題に対して、時機を得た効率的な方法で応答するのに十分な処理能力を有することができる。

基本的には、プロセスモジュールは、センサーと同様の振る舞いをするので、本発明の１態様によれば、プロセスモジュールは、ＲＡＣＣＭに対するもう１つの「部品」であるように見える。説明を容易にするために、「部品」という用語は、プラズマ処理システムにおけるデータ収集部材を言及するのに使用する。ある例では、部品は、プロセスモジュール、センサーおよび計測ツールを含みうるが、これに限定されるわけではない。

ある実施形態では、ＲＡＣＣＭ２１２は、サーバーなどのコンピュータシステムであってもよい。ある実施形態では、ＲＡＣＣＭ２１２は、データ管理および／またはレシピ管理を行うための１つまたは複数のプロセッサを有しうる。プロセッサの数は、ＲＡＣＣＭの実装により異なりうる。ある実施形態では、ＲＡＣＣＭ２１２は、メモリも有しうる。メモリの量は、ＲＡＣＣＭの記憶要件を鑑みて、容易にかつ安価に拡張できる。

ある実施形態では、ＲＡＣＣＭ２１２は、データを管理し、レシピ管理を行うための知能を有することができる。ある例では、ＲＡＣＣＭ２１２は、入ってくるデータファイルを受付け、データを処理し、データ要求を取り扱い、レシピを分配するなどのための条件を設定するための知能を有することができる。収集されたデータを処理するための知能が、プロセスモジュールのみにより取り扱われる従来技術とは異なり、ＲＡＣＣＭ２１２中でデータを処理する知能は、ＲＡＣＣＭ２１２内の様々なエージェント間で分配されることができる。ある実施形態では、ＲＡＣＣＭ２１２は、複数の知的エージェント（２１４、２１６、２１８、２２０および２２２）と、１つの調整エージェント２４６と、臨時エージェント２４８とを含むことができる。複数の実体間で知能を分配することにより、作業負荷は分配されることができ、したがって、より効率的な処理環境が可能となる。この結果、データ通信量の混雑および待ち時間は低減し、より安定的な環境を得ることができる。

ある実施形態では、ＲＡＣＣＭ２１２は、複数の知的エージェント（２１４、２１６、２１８、２２０および２２２）を含むことができる。各知的エージェントは、部品（２０４、２０６、２０８および２１０）と関連付けることができる。ある例では、知的エージェント２１４は、センサー２１０と関連付けられる。ある実施形態では、データがＲＡＣＣＭ２１２にアップロードされる時、センサー２１０が、経路２２４・２２６で、データファイルを送信し、これが、知的エージェント２１４により受領される。同様に、プロセスモジュール２０２は、対応する知的エージェント２２２を有することができ、この知的エージェント２２２は、経路２２４・２２８でプロセスモジュール２０２が送信したデータを受領するように構成されている。

ある実施形態では、各知的エージェント（２１４、２１６、２１８、２２０および２２２）は、対応する部品に対して構成要件を送るための知能を有することができ、これにより、データファイルをアップロードするための基準を提供する。従来技術では、センサーは、前処理なしに、プロセスモジュールに対してデータをアップロードする可能性があった。あるいは、センサーはデータ分析および操作を行うために、プロセスモジュールを頼りにする傾向がある。従来技術とは異なり、以前には、プロセスモジュールに存在していた知能の１部分は、ここでは、センサーレベルに引き下げることができる。ある例では、知的エージェントにより提供された構成要件は、センサーに対して、データをアップロードするための基準を提供することができる。構成要件を適用することにより、センサーは、前処理を行う（例えば、変更されたのが何であるかを決める）ことができ、知的エージェントに対して、知的エージェントが必要とするデータのみを提供することができ、したがって、ネットワークの混雑を低減する。

ある実施形態では、知的エージェントは、対応する部品に対して、プロセス制御速度未満の時間領域でのみデータを送信するように指示する構成要件を送ることができる。説明を容易にするために、「期間」という用語は、プロセス制御速度を暗示するためにも用いることができる。例えば、プロセス制御速度が、例えば、１２５μ秒毎であると決定したという状況を考慮されたい。知的エージェント２１４は、センサー２１０に対して構成要件を送り、センサー２１０に対して、１００μ秒毎の時間領域でデータを送るように指示することができる。したがって、知的エージェント２１４が、そのデータを調整エージェント２４６（これは、様々な知的エージェントからデータを収集し処理するように構成されうる）に対して提供しなければならなくなる前に、知的エージェント２１４には、センサー２１０からデータを受領しかつそのデータを処理する十分な時間がある。

時間領域を設定することにより、知的エージェントは、いつデータファイルを受領するかを制御可能となる。従来技術では、各センサーからのデータファイルを調和させるのは、不可能でなくても困難なタスクであるが、これは、データファイルが異なる期間で収集されていたからである。しかしながら、本発明の実施形態は、ある期間（プロセス制御速度）の間の時間領域は少なくとも１度であると要求することができる。したがって、ある１つの期間中に様々な知的エージェントにより受領可能な複数のデータファイルは適合され、データの共有がより容易になり、より包括的な分析が可能となる。

知的エージェントがどれほどの頻度でデータファイルを要求することができるかは、個々にプログラムすることができる。ある例では、センサー２１０は、５０μ秒毎にデータを収集することができる。ある実施形態では、知的エージェントは、データファイルが生成されるたびに、センサーがデータファイルをアップロードするよう要求することができる。ある例では、センサー２１０がデータを受領するたびに、知的エージェント２１４がデータを収集するよう選択することができる。換言すれば、センサー２１０は、５０μ秒毎に更新したデータファイルを知的エージェント２１４に対して送ることができる。

別の実施形態では、知的エージェントは、乗数（multiplier）に基づいて、データファイルを要求することができる。ある例では、センサー２０８は、２５μ秒毎にデータを収集することができる。したがって、各期間（１１０μ秒のプロセス制御速度）に対して、センサー２０８は、少なくとも４セットのデータファイルを生成することができる。知的エージェント２１６は、センサー２０８が２の乗数でのみ（例えば、５５μ秒毎）データを送るように構成することができる。これゆえに、センサー２０８は、収集することができた４つのデータファイルではなく、２つのデータファイルのみを送ることができる。例えば、センサー２０８は、５５μ秒毎に、知的エージェント２１６に対して、生成された中で最新に更新されたデータファイルを送ることができる。

さらに別に実施形態では、知的エージェントは、期間毎に一度のみ、収集を行うことができる。ある例では、知的エージェント２１４は、１００μ秒毎にデータを収集することができる。知的エージェント２１４は、センサー２１０により収集された、これ以外のいずれのデータファイルをも無視する。ある実施形態では、知的エージェント２１４は、追加のデータファイルが生成されたことを知らないことがありえるが、これは、知的エージェント２１４が、１００μ秒毎にデータファイルを受領することのみに関心があるからである。時間領域を制御することにより、ネットワーク経路でのデータ通信量の混雑を管理することができる。さらに、必要な際にのみデータを収集することにより、部品から受け取った各データファイルを処理するのに要求される処理力を最低限にすることができる。したがって、待ち時間を有意に低減することができ、ネットワークはより信頼性を有するようになる。

タイミング指示を有する構成要件を送る以外に、知的エージェントは、データファイルを送る条件を規定する基準を有する構成要件を、部品に送ることもできる。ある例では、知的エージェント２１４は、センサー２１０により収集されるパラメータの最低領域および最高領域を規定することができる。例えば、パラメータが特定の範囲外にある場合には、知的エージェント２１４は、新規のデータファイルのみを送るように、センサー２１０に対して指示することができる。これにより、パラメータ用に収集されたデータが特定の範囲内にある限り、新規のデータファイルは、知的エージェント２１４にはアップロードされるにはおよばない。

新規のデータファイルがアップロードされうる条件を規定することにより、知的エージェントは、ネットワーク経路（例えば、経路２２４）でのデータ通信量の混雑を最低限に抑えることができる。また、知的エージェントは、データ分析全体に対してほとんどあるいは全く貢献しえないオーバヘッドコスト（例えば、データを記憶および処理するための不必要なメモリ使用や処理力の使用）を低減することができる。

ある実施形態では、知的エージェントにより最新に受領されたデータファイルは、各知的エージェント中に位置づけられるキャッシュ（２３０、２３２、２３４、２３６および２３８）中に保存されうる。別の実施形態では、このキャッシュは、１つまたは複数のデータファイル（最新のデータファイルおよびいくつかの過去のデータファイル）を保存することができる。データファイルをキャッシュに保存することにより、このデータファイルは、分析のためおよび／または他のエージェント（例えば、知的エージェント、調整エージェント、臨時エージェントなど）と共有するために利用可能である。ある例では、キャッシュを採用することにより、新規のデータがアップロードされていない場合でも、知的エージェントは、要求する実体に対してデータを提供することができる。

ある実施形態では、１つ以上のデータファイルが、ある期間内に受領された場合には、最新のデータファイルのみが共有される。ある例では、センサー２０８は、知的エージェント２１６に２セットのデータファイル、すなわち、データストリームａおよびデータストリームｂを送ったが、ここで、データストリームｂが最新のデータストリームである。調整エージェント２４６が、知的エージェント２１６からデータファイルを要求する際には、知的エージェント２１６は、調整エージェント２４６と、最新のデータファイル（データストリームｂ）を共有することができる。

ＲＡＣＣＭ２１２は、臨時エージェント２４８を有することができるが、この臨時エージェント２４８は、様々な異なるレシピを受け付け、このレシピを様々な知的エージェント間に分散させるために採用されうる。例えば、レシピが修正されたという状況を考慮されたい。様々な異なるセンサーおよびプロセスモジュールにおいて、レシピを手動で更新するのではなく、レシピは、１つの中央集中化された領域で修正されることができる。更新されたレシピは、ホストにアップロードされることができ、このホストが、プロセスモジュール２０２と更新されたレシピを共有する。ある実施形態では、プロセスモジュールは、処理モデルに関するレシピの１部分をコピーすることができる。別の実施形態では、プロセスモジュールは、更新されたレシピのいずれの部分も保存しないと選択することができる。そして、プロセスモジュールは、何があろうとも更新されたレシピを臨時エージェント２４８に転送する。

臨時エージェント２４８は、レシピを再検討して、様々なエージェント（例えば、知的エージェントおよび／または調整エージェント）に、このレシピの様々な部分を分配することができる。例えば、レシピは異なるパラメータを含みうる。これらのパラメータの各々は、１つまたは複数のセンサーに関連がありうる。臨時エージェント２４８は、どの知的エージェントが更新されたレシピのどの部分を必要としうるかを決める知能を有することができる。臨時エージェント２４８により、レシピは一度アップデートされ、様々なエージェント間で自動的に分配されることができる。

レシピを様々な部品（センサー、計測ツール、および／またはプロセスモジュール）で保存する代わりに、この場合、レシピはエージェント間で分配される。従来技術とは異なり、知的エージェントが、包括的なデータ分析をすることができるようにするため、レシピは、知的エージェントが容易に利用できる。ある実施形態では、データ分析を容易にするため、調整エージェントは、全レシピの高度レベルのコピーを有する。ある例では、各知的エージェントにおいて保存することができるレシピの部分は、その知的エージェントに関連付けられうるセンサーに関するレシピの全部分を含むことができる。調整エージェントは、知的エージェントが必要としうる詳細を必要とはしないので、ある例では、調整エージェントにおいて保存されることができるレシピは、各パラメータがレシピ実行のためにいかに互いに関連付けられるかを規定しうるレシピの部分のみを含みうる。

ある実施形態では、各知的エージェントは、異なるデータ関連タスク（データ要約、知的エージェントに保存されたレシピに基づく評価項目検出および障害検出など）を実施するための知能を有することができる。ある例では、データファイルが一度受領されると、知的エージェントは、特定の期間で収集されたデータを要約することができるシグネチャデータを作るためのデータ分析を行うことができる。例えば、受領したデータファイルに基づいて、および、知的エージェント２１４に保存されたレシピに基づいて、評価項目が検出された。様々なデータ点を取り入れることにより、知的エージェントは、知的エージェントが共有することができるシグネチャデータを作ることができる。ある実施形態では、各知的エージェントは、調整エージェントとシグネチャを共有している。ある例では、調整エージェント２４６は、各期間において、各知的エージェントからシグネチャデータを受領するように構成されうる。

したがって、様々な知的エージェントに分配された知能は、分析を行い、調整エージェントが必要としうるデータを提供できる。ある実施形態では、調整エージェントは、複数のシグネチャを受領すると、調整エージェントに保存されたレシピに基づいて、様々な異なるデータシグネチャを分析し、複合的なシグネチャを生成する。この複合的なシグネチャは、このデータを必要としうる部品間で共有することができる。ある実施形態では、調整エージェントは、複合的なシグネチャに基づいて作用を行うことができる。

調整エージェントは、ＲＡＣＣＭにアップロードされうる過剰のデータに圧倒されることがないので、調整エージェントは、レシピの全体的な実行状態を決めるのに必要とされるデータに集中することができる。この結果、調整エージェントは、潜在的な問題に迅速に応答することができる。ある例では、現在の基板処理に存在しうる問題を示す複合的なシグネチャを生成するために、知的エージェントから受領したシグネチャセットに基づいて、調整エージェント２４６は、調整エージェントレベルで保存されたレシピに対してデータ分析を行うことができる。したがって、プロセスモジュール２０２に対して停止実行メッセージを送ることにより、調整エージェント２４６は迅速に応答することができる。

複合的なシグネチャが、プロセスモジュールの作用を即時に必要とする場合、調整エージェント２４６とプロセスモジュール２０２との間の通信を容易にするために、専用チャネル（例えば、専用チャネル２４０）が設けられている。専用チャネルは、一般的なネットワーク経路（例えば、経路２２４）での潜在的な通信量の混雑に対処することなく、調整エージェントが迅速にプロセスモジュールに通知可能にする。ある実施形態では、プロセスモジュール２０２の作用が即時に要求されない場合、調整エージェント２４６は、一般的なネットワーク経路（経路２２４）でプロセスモジュール２０２と通信することができる。

ある実施形態では、調整エージェントは、様々な知的エージェント間でのデータの共有を調整するためにも採用される。ある例では、知的エージェント２１４は、知的エージェント２１６により保存されたデータを必要としうる。データを要求するために、これらの知的エージェントは互いに通信を行いうる。しかし、要求されたデータが、複数の知的エージェントからやってくる場合、異なる知的エージェントと個々に調整するのではなく、複数のデータを調整エージェントから取り出すのがより効率的である。

さらに別に実施形態では、調整エージェントは、トラブルシューティングを行うために必要とされうるデータを取り出すためにも採用可能である。ある例では、調整エージェント２４６は、トラブルシューティングを行うために採用されるコンピュータシステム２４４に接続されることができる。トラブルシューティングを行うコンピュータシステム２４４がデータを必要とする場合、要求が、経路２５０を介して調整エージェント２４６に送られる。調整エージェント２４６は、要求されたデータを取り出し、それをトラブルシューティングを行うコンピュータシステムに送ることができる。

図２に示すように、ＲＡＣＣＭは、処理システムのためにデータを取り扱いかつレシピ管理をすることができる制御モジュールである。従来技術とは異なり、プロセスモジュールでは、データの収集、取り扱いおよび調整を行うための中央集中モジュールとしての機能はなくなっている。これに代えて、新しいＲＡＣＣＭ環境中のプロセスモジュールは、データ管理およびレシピ管理における複数のセンサーのうちの１つのセンサーのように振舞いうる。ある実施形態では、基板をより精確に処理できるように、より多くのセンサーが必要であるが、ＲＡＣＣＭを、比較的容易におよび安価に修正して、メモリ容量を増やし、処理力を高めることができる。ＲＡＣＣＭは、複数の実体（例えば、知的エージェント、調整エージェント、臨時エージェント）を含むことができるので、１つの実体が全てのタスクを実施するために不必要に負荷を受けないように、作業負荷を分配することができる。作業負荷を分配することにより、従来技術では存在しえたデータ通信量の混雑および待ち時間を有意に低減し、データ共有およびデータ分析のためにより安定したネットワークを提供することができる。

図３〜８は、本発明の実施形態におけるＲＡＣＣＭの実装方法を示す図である。

図３は、本発明の１実施形態におけるセンサーの構成工程を示す単純なフローチャートである。

第１工程３０２で、知的エージェントは、臨時エージェントからレシピを受領することができる。上述したように、この臨時エージェントは、レシピを必要としうる実体に対してレシピを分配することによりレシピ管理を行うことができる。ある実施形態では、レシピの１部分のみが、１つの特定の任意の実体に分配されることができる。ある例では、知的エージェント２１４は、センサー２１０が関連しうるパラメータに関するレシピの１部分のみを必要とすることができる。

次の工程３０４では、知的エージェントは、レシピに基づいて構成要件を生成することができる。ある実施形態では、構成要件は、いつ、センサーが知的エージェントに対してデータファイルを送ることができるかを規定する基準を含むことができる。ある例では、構成要件は、時間領域（例えば、データファイルがどのくらいの頻度で送られうるかに関する指示など）を含むことができる。別の実施形態では、構成要件は、知的エージェントにデータファイルを送るためのデータの条件を含むことができる。ある例では、パラメータが特定の範囲内にある場合にのみ、データファイルがアップロードされることができる。

次の工程３０６では、知的エージェントは、対応するセンサーに構成要件を通信することができる。ある例では、知的エージェント２１４は、この構成要件に関してセンサー２１０と通信することができる。ある実施形態では、センサーは、この構成要件を適用する知能を有し、いつデータファイルが知的エージェントに送られるべきであるかを決める。ある例では、構成要件は、データファイルを１００μ秒毎に送るという指示を出すことができる。しかしながら、このセンサーは、データを５０μ秒毎に収集することができる。このセンサーは構成要件を適用することができ、センサーが頻繁にデータを収集していたとしても、構成要件に従ってのみデータファイルを送ることができる。別の例では、センサーは複数のデータファイルを収集したが、パラメータの変更が構成要件に合うことができないので、センサーはデータファイルを知的エージェントに送ることはできない。

構成要件を介してデータファイルの送信を管理することにより、知的エージェントは、センサーと連動して、ネットワーク上のデータ通信量を管理することができる。従来技術でのプロセスモジュールとは異なり、知的エージェントは、センサーによりアップロードされるデータの量を制御することができ、したがって、不必要なデータ通信量の混雑を有意に低減することができる。

図４は、本発明の１実施形態における、知的エージェントがキャッシュから要約データを生成する工程を示す単純なフローチャートである。

第１工程４０２では、知的エージェントはセンサーからデータを受領することができる。ある例では、知的エージェント２１４は、センサー２１０からデータファイルを受領する。ある実施形態では、このアップロードされたデータファイルは、（図３中で説明したように）構成要件に基づいている。別の実施形態では、入ってくるデータファイルは、キャッシュに保存することができる。キャッシュは、１つまたは複数のデータファイルを含むことができる。ある例では、キャッシュは、最新のデータファイルおよび／または複数の最近のデータファイルを含むことができる。データファイルをキャッシュに保存することにより、分析のため、データ操作のため、および要求する実体（例えば、調整エージェント、他の知的エージェントなど）と共有するために、このデータファイルを利用することができる。

さらに、データをキャッシュに保存することにより、データラッチが生じうる。換言すれば、センサーは新規のデータを収集しておらず、知的エージェントにアップロードされるべき新規のデータファイルは入手可能ではない。したがって、プロセスモジュールが知的エージェントから更新データを要求するときには、（新規のファイルがアップロードされていないが、それでも）知的エージェントはデータファイル（現在キャッシュに保存されているデータファイル）をプロセスモジュールに提供することができる。

次の工程４０４では、知的エージェントはデータを演算することができる。ある実施形態では、データ演算は、知的エージェントに保存されているレシピに基づいている。別の実施形態では、別の実体（例えば、調整エージェント）がデータを要求した際に、データ演算が行われうる。ある例では、調整エージェントが、１２５μ秒毎にシグネチャデータ（例えば、評価項目（endpoint）、障害検出データなど）演算するよう要求する。したがって、データファイルを受領すると、知的エージェント２１４は、調整エージェント２４６と共有することができるシグネチャを作るために、局所的に保存されたレシピに基づいて受領したデータを分析することができる。

次の工程４０６では、知的エージェントは要求する実体にデータを提供することができる。ある例では、知的エージェントは、１２５μ秒毎にシグネチャデータを調整エージェントに送ることができる。ある実施形態では、データが更新されていない場合、データファイルを送ることができない。ある例では、知的エージェント２１４は、センサーから更新されたデータファイルを受領していないが、これは、新規のデータファイルの基準に合っていないからである。したがって、知的エージェントが、次の要求に対して、更新されたシグネチャを調整エージェント２４４に提供せねばならないときは、知的エージェント２１４は、更新されたシグネチャファイルを送ることができない。ある実施形態では、調整エージェントは、更新されたシグネチャがない場合は、現在のシグネチャが変更されていないことを示すと結論付けることができるという知能を有することができる。

従来技術中のプロセスモジュールとは異なり、単一のエージェントのみがデータ管理に責任を持つのではない。これとは異なり、データ分析、データ操作およびデータ調整用の知能を複数のエージェント間で分配することにより、作業負荷が多くの異なる実体間で分配される。したがって、より効率的なデータ管理が、複数のエージェント間での調和により達成されうる。さらに、知的エージェントにデータ管理をさせることにより、プロセスモジュールはその責任から解放され、代わりに、プロセス制御管理というその主要なタスクに集中する。

図５は、本発明の１実施形態における、知的エージェントが評価項目および／または障害検出データを生成する工程を示す単純化したフローチャートである。

第１工程５０２では、知的エージェントは、センサーからデータを受領することができる。ある例では、知的エージェント２１４は、センサー２１０からデータファイルを受領することができる。上述したように、アップロードされるデータファイルは、（図３中で説明したように）構成要件に基づいている。

次の工程５０４では、知的エージェントは、評価項目および／または障害検出を特定するために、データファイルを分析することができる。ある例では、局所的に保存されたレシピに基づいて、知的エージェント２１４は、受領したデータファイルに基づいて評価項目を特定することができる。別の例では、知的エージェントは、障害検出を行うためにデータファイルを分析することができる。ある実施形態では、障害検出を行うことは、受領したデータを、知的エージェントで局所的に保存されたレシピに対して比較する工程を含むことができる。

次の工程５０６では、知的エージェントは、評価項目および／または障害検出データを、要求する実体に提供することができる。ある実施形態では、知的エージェントから調整エージェントに送られるデータは、要約データ（例えば、シグネチャファイル、評価項目など）である。換言すれば、調整エージェントは、センサーから収集されたデータの要約を受領し、したがって、上流に送られるデータの量は、はるかに少なくなるが、これは、知的エージェントがすでにデータ分析およびデータ操作を行っているからである。ある例では、完全なデータファイルを送る代わりに、知的エージェント２１４は、評価項目のみを調整エージェント２４６に対して送ることができる。

評価項目を受領すると、調整エージェントは、評価項目を局所的に保存されたレシピに対して比較する。ある実施形態では、調整エージェントにおいて保存されたレシピは、複数の知的エージェントにおいて保存されうるレシピを含むことができる。しかしながら、調整エージェントは、各知的エージェントに保存されることができる完全なレシピの詳細を保存しないかもしれない。これに代えて、調整エージェントは、高レベルの組み合わせ分析を行うことができるような小さい部分のみを保存しうる。ある例では、知的エージェント２１４から受領した想定される評価項目が実際に評価項目であるか否か、あるいは、調整エージェントがより多くのデータを要求する必要があるかを、調整エージェントが決定するのに十分なレシピを、調整エージェントは保存することができる。

従来技術とは異なり、プロセスモジュールは、評価項目特定および／または障害検出を行うためにデータを分析する責任を持たない。これに代えて、このタスクは、局所的に保存されたレシピに基づいて、評価項目ないし障害検出のデータを決定するために、このデータを分析することができる複数のエージェント間で分配される。ここでも、評価項目特定および／または障害検出を行うために知能を分配することにより、この作業負荷は、多くの異なるエージェント間で分配される。また、ネットワーク上のデータ通信量の混雑は、有意に低減できるが、これは、複数の知的エージェントが、単一のプロセスモジュールよりも多くの量のデータを取り扱うことができるからである。したがって、より安定したネットワーク環境が存在することができ、プロセスモジュールは、プロセス制御を行うタスクに集中することができる。

図６は、本発明の１実施形態において、調整エージェントがデータ分析を行う工程を示す単純化したフローチャートである。

第１工程６０２では、調整エージェントは、複数の知的エージェントからデータを受領することができる。ある実施形態では、調整エージェントへアップロードされるデータは、評価項目および障害検出データなどの要約データでありうる。

次の工程６０４では、調整エージェントは、ある作用が行われる必要があるか否かを決定することができる。ある実施形態では、調整エージェントにおいて局所的に保存されたレシピに基づいて、調整エージェントは出力を生成することができる。ある例では、調整エージェント２４６は、１つまたは複数の評価項目が実際に特定されたか否かを決めるために、複数の知的エージェントから送られたデータを分析することができる。別の例では、調整エージェント２４６は、複合的なシグネチャを生成するために、局所的に保存されたレシピに基づいて、データの更なる分析をすることができる。

ある作用が必要とされた場合、次の工程６０６において、調整エージェントはその作用を行うことができる。ある例では、評価項目が特定されると、調整エージェントは１つまたは複数の作用を行わねばならないかもしれない。例えば、調整エージェントは、プロセスモジュールに対して評価項目について通知せねばならないかもしれない。別の例では、複合的なシグネチャは、問題が存在しうることや、プロセスモジュールは操作を終了せねばならないということを示すかもしれない。ある実施形態では、その作用が重大ではない場合、調整エージェントは、対応する知的エージェントを介してプロセスモジュールに通知する。しかしながら、その作用が重大である場合、調整エージェントは、専用チャネル２４０などの専用チャネルを介して、直接プロセスモジュールに通知することができる

作用が要求されない場合、調整エージェントは工程６０２に戻り、複数の知的エージェントからデータを受領し続けることができる。

調整エージェントが受領するデータは、センサーから送られたデータの要約であるので、この調整エージェントがデータ分析を行う必要がない多量のデータにより、調整エージェントが圧倒されることはない。したがって、調整エージェントは、迅速にデータ分析を行い、いずれの要求に対しても、および／または、特定されることができる潜在的な問題に対しても容易に応答することができる。したがって、調整エージェントは、プロセスモジュールから、データ調整およびデータ分析などのタスクをオフロードすることができる。

図７は、本発明の１実施形態において、臨時エージェントを介してＲＡＣＣＭの異なる実体間でレシピを分配する工程を示す単純化したフローチャートである。

第１工程７０２では、レシピがプロセスモジュール上に取り込まれる。例えば、レシピが変更されたという状況を考慮されたい。従来技術では、レシピが変更された場合、その変更は、異なる部品（例えば、１つまたは複数のセンサー、プロセスモジュールなど）において、個々に更新される必要がありえる。従来技術とは異なり、この変更は、１つの中央集中化した記憶場所で更新される。その後、更新されたレシピはプロセスモジュールへアップロードされる。

次の工程７０４では、プロセスモジュールは、レシピを臨時エージェントへアップロードすることができる。ある実施形態では、プロセスモジュール２０２は、修正されたレシピを対応する知的エージェントへアップロードすることができる。ある例では、プロセスモジュール２０２は、レシピを知的エージェント２２２へアップロードすることができる。レシピを受け取ると、知的エージェント２２２はそのレシピを臨時エージェント２４８に転送することができる。ある例では、知的エージェント２２２は、修正したレシピを、経路２４２で臨時エージェント２４８へ送る。

次の工程７０６では、臨時エージェントはＲＡＣＣＭ内の様々な異なるエージェント間で、レシピを分配することができる。ある実施形態では、レシピは、エージェント（知的エージェントないし調整エージェント）と部品との間の関係を元に分配されることができる。ある例では、知的エージェント２２２は、プロセスモジュール２０２に関連付けられる。したがって、知的エージェント２２２は、プロセスモジュール２０２が必要とするレシピの部分のみを受領することができる。

ＲＡＣＣＭがレシピを保存かつ管理することにより、レシピの更新は迅速に行われることができる。従来技術とは異なり、レシピは一度だけ更新され、したがって、人的ミスの危険性を最低限に抑えることができる。さらに、レシピを分配するタスクは自動化することができ、したがって、部品のうちの１つにおいて更新が行われないという可能性を低減することができる。現実的には、レシピは、様々な部品に分配される必要はもはやないが、これは、そのレシピが知的エージェントにあり、これらの部品に構成要件を提供するからである。

ＲＡＣＣＭ内の複数のエージェントに渡ってレシピを分配することにより、レシピはデータ操作およびデータ分析を行わねばならない可能性がある異なる実体間で利用可能となる。ある例では、知的エージェント２２２がデータ分析を行う。しかしながら、正確な分析を行うために、知的エージェント２２２は、知的エージェント２１４に保存されているレシピにアクセスする必要がありうる。レシピはＲＡＣＣＭ内で局所的に保存されているので、知的エージェント２２２は容易に、知的エージェント２１４と通信し、要求されるレシピを取り出すことができる。

図８は、本発明の１実施形態において、部品を知的エージェントと関連付けるための工程を示す単純なフローチャートである。

第１工程８０２で、部品は、処理システムに加えられる。例えば、新規のセンサーが処理システムに加えられたという状況を考慮されたい。ある実施形態では、センサーが初めてＲＡＣＣＭに接続されると、センサーは自身の存在を知らせる。この新規のセンサーの存在は、少なくとも３つの異なる方法で、ＲＡＣＣＭに知らせることができる。

次の工程８０４で、この方法では、部品がＲＡＣＣＭに通知するか否かを決定する。ある実施形態では、部品は、ＲＡＣＣＭに報告データパッケージを送ることができる。ある例では、センサー２１０は、ＲＡＣＣＭ２１２に報告データパッケージを送ることができる。報告データパッケージは、そのセンサーに関するプロフィールデータを含みうる。

次の工程８０８では、ＲＡＣＣＭは知的エージェントを起動させることができる。報告データパッケージを受け取ると、ＲＡＣＣＭ２１２は、通信を開始したいセンサーを特定するために、報告データパッケージを分析することができる。ある実施形態では、ＲＡＣＣＭは、複数の知的エージェントを有することができるが、１つまたは複数の知的エージェントが休止したままかもしれない。ある例では、ＲＡＣＣＭは１００個の知的エージェントを有することができるが、センサーがＲＡＣＣＭに接続されるまでは、各知的エージェントは休止状態である。

ある実施形態では、ＲＡＣＣＭはある知的エージェントを起動させ、この知的エージェントを、要求するセンサーと関連付けることができる。ある実施形態では、始動時に、知的エージェントクラスが、ＲＡＣＣＭに取り込まれることができる。センサーが自身の存在を最初に通知すると、ＲＡＣＣＭは、関連する知的エージェントクラスから１つの知的エージェントオブジェクトのインスタンスを作成する。知的エージェントオブジェクトのインスタンスが作成されると、知的エージェントは、例えば、目標センサーに対する通信シーケンスのインスタンスを作成し始めることができる。

ある例では、ＲＡＣＣＭ２１２が知的エージェント２１４をセンサー２１０に割り当てるまでは、その知的エージェント２１４は休止したままである。ある実施形態では、知的エージェントが起動されると、臨時エージェントは、新規のセンサーに関連しうるレシピを送ることができる。ある例では、センサー２１０が、処理システムに追加された。ほぼ同時に、センサー２１０がこれから収集するデータの新規のパラメータの説明をするように、レシピは修正されえた。修正されたレシピは、臨時エージェント２４８に取り込まれ、この臨時エージェント２４８が、知的エージェント２１４に対して、このセンサー２１０に関連しうるレシピの１部分を分配することができる。

次の工程８１０で、知的エージェントは、部品に構成要件を送ることができる。ある例では、知的エージェント２１４が起動されると、知的エージェントは、構成要件（例えば、時間領域、データストリーム条件など）をセンサー２１０に送り始める。知的エージェントは、すでにＲＡＣＣＭに予め取り込まれているので、センサーが処理システムに接続されるとほぼ即時に、センサーはプラグ・アンド・プレイ能力を有することができる。

工程８０４に戻ると、部品がＲＡＣＣＭに対してその存在を自動的に通知できない場合、次の工程８０６において、人間のユーザが、ＲＡＣＣＭに通知する。ある例では、技術者がセンサー２１０を処理システムに接続する。

次の工程８０８では、ＲＡＣＣＭが知的エージェントを起動することができる。ある例では、技術者がセンサーに対応する知的エージェントをＲＡＣＣＭ２１２上にダウンロードすることができるが、これは、ＲＡＣＣＭ２１２をセンサー２１０と通信させるために行われる。ある例では、知的エージェント２１４は、ＲＡＣＣＭ２１２にダウンロードされることができる。換言すれば、部品が、その存在をＲＡＣＣＭに自動的に通知することができない場合、技術者は手動で関連する知的エージェントクラスから知的エージェントオブジェクトのインスタンスを作成することができる。知的エージェントオブジェクトのインスタンスが作成されると、これは、目標とするセンサーへ通信シーケンスを開始する。

上述（工程８１０）と同様、知的エージェント２１４が起動されると、知的エージェントは、構成要件（例えば、時間領域、データストリーム条件など）をセンサー２１０に送り始める。有利なことに、起動された知的エージェントのみを維持することにより、ＲＡＣＣＭのメモリ要件を最小限に抑えることができる。

工程８０６に戻って、人的介入が生じない場合、次の工程８１２において、ＲＡＣＣＭは自己発見（self-discovery）を行うことができる。例えば、新規のセンサーが処理システムに接続されたという状況を考慮されたい。しかしながら、センサーは自己報告データパッケージを送る能力を有することできず、人的介入も起こることができなかった。ある例では、センサー２１０が処理システムに追加された。しかしながら、センサー２１０には、その存在をＲＡＣＣＭ２１２に宣言する方法がない。

ある実施形態では、ＲＡＣＣＭは自己発見特徴を有し、これにより、ＲＡＣＣＭは周期的に処理システムをチェックすることができ、これにより、変更（例えば、新規のセンサー、処理システムの変更など）が生じたか否かを決めることができる。別の実施形態では、自己発見特徴は、割り込みイベントを含み、これは、処理システムに変更が起きたときにＲＡＣＣＭに対して通知するために採用することができる。新規のセンサーが処理システムに追加されたと、ＲＡＣＣＭが決めると、ＲＡＣＣＭはその新規のセンサーとの通信を確立し、センサーのプロフィールを獲得する。

プロフィール獲得が行われると、次の工程８０８では、ＲＡＣＣＭは、上述の新規のセンサーに対応しうる知的エージェントを起動させることができる。ある実施形態では、この知的エージェントは、すでに、ＲＡＣＣＭ中にありうる。別の実施形態では、ＲＡＣＣＭは、その知的エージェントをダウンロードせねばならないことがありうる。自己発見により、ＲＡＣＣＭは、異なる種類のセンサー（例えば、自己報告型センサー、非自己報告型センサーなど）を多様に取り扱う。

上述より明らかなように、本発明の実施形態は、プロセスモジュールのデータ管理の負荷を実質的に低減している。ＲＡＣＣＭを採用することにより、プロセスモジュールは、ＲＡＣＣＭの機能から利益を受けうるもう１つの部品に過ぎないように見えるアーキテクチャシステムが作られている。ＲＡＣＣＭにより、ネットワーク内の待ち時間およびデータ通信量の混雑が有意に低減されることができるが、これは、データ管理が異なるエージェントおよび部品間で分配されるからである。さらに、より包括的なデータ分析が行われることができるが、これは、エージェント間でデータおよび／またはレシピが共有されるからである。プロセスモジュールを、時間がかかり複雑なデータ管理タスクから解放することにより、プロセス制御のタスクおよびデータ管理のタスクが、同じ資源を求めて互いに争うことはもはやなくなる。

本発明は、いくつかの好適な実施形態の観点から説明したが、本発明の範囲内に入る変更、置換および等価物が存在する。様々な例が本願中で挙げられたが、これらの例は例示であり、本発明を限定する意図はない。

また、発明の名称および要約は、本願中で便宜上提供されたのみであり、本願請求項の範囲を解釈するために用いられるべきではない。さらに、概要は多いに省略された形態で書かれ、これも本願中で便宜上、提供されたものであり、発明全体を解釈または限定する目的で用いられるべきではない。発明全体は、請求項中に記載されている「セット」という用語を本願中で用いる場合、この用語は、０、１または１を上回る数字を網羅する一般的に理解される数学的な意味があることを意図している。本発明の方法および装置を実装する多くの代替方法が存在することに注目すべきである。それゆえに、以下の添付の請求項は、このような全ての変更、置換および等価物が本発明の真の精神および範囲内に入るものとして、これらを含むと解釈されることが意図される。

Claims (16)

1. プラズマ処理システム中でのデータ管理を行うサーバーであって、前記プラズマ処理システムは、複数の部品と接続されまたは接続された状態にあり、前記サーバーは、
   複数の知的エージェントであって、前記複数の知的エージェントの各知的エージェントは、前記複数の部品のうちの１つの部品と相互作用するように構成されており、
   前記各知的エージェントは、各基準に基づいて、前記部品からデータを受領するように構成され、
   前記複数の知的エージェントから処理されたデータを受領するように構成されている調整エージェントを備え、
   さらに、臨時エージェントセットを有し、前記臨時エージェントセットは、レシピ管理を行うように構成され、前記レシピ管理は、レシピの少なくとも１部分を、前記複数の知的エージェントおよび前記調整エージェントのうちの少なくとも１つに分配することを特徴とするサーバー。
2. 前記複数の知的エージェントの前記各知的エージェントは、前記複数の部品のうちの前記部品のために、構成要件を規定するための知能を有し、前記構成要件は、前記複数の知的エージェントの前記各知的エージェントに、データファイルを送るための基準を含み、前記基準は、前記複数の知的エージェントの前記各知的エージェントで局所的に保存された前記レシピの前記１部分に基づいている請求項１に記載のサーバー。
3. 前記複数の知的エージェントに前記データファイルを送る前に、前記複数の部品は、前記データファイルに対して前処理を行うために前記構成要件を用いる請求項２に記載のサーバー。
4. 前記複数の知的エージェントの前記各知的エージェントはキャッシュを有し、前記キャッシュが、データラッチを可能にするために少なくとも最新のデータファイルを保存するように構成されている請求項３に記載のサーバー。
5. 前記複数の知的エージェントの前記各知的エージェントは、シグネチャデータを生成するために、前記データファイルのデータ分析を行い、前記シグネチャデータは、前記データファイル用の要約データである請求項４に記載のサーバー。
6. 前記調整エージェントは、前記複数の知的エージェントの各知的エージェントから、前記シグネチャデータを受領するためのコードを有するように構成され、前記調整エージェントは、複合的なシグネチャを生成するためにデータ分析を行う請求項５に記載のサーバー。
7. 前記調整エージェントは、前記複合的なシグネチャに基づいて、前記複数の部品に対して指示を提供するための知能を有する請求項６に記載のサーバー。
8. 前記複数の部品は、プロセスモジュール、センサーおよび計測ツールのうちの少なくとも１つを含む請求項７に記載のサーバー。
9. 前記サーバーは、前記プラズマ処理システムに対する変更を特定するために自己発見をする知能を有し、前記自己発見は、前記複数の部品の１つの部品が前記プラズマ処理システムに接続されたかを特定することを含む請求項１に記載のサーバー。
10. コンピュータで読み取り可能なコードが中に埋め込まれたプログラム記憶媒体を有する製造品であって、
    前記コンピュータで読み取り可能なコードは、プラズマ処理システム用のデータ管理を行うよう構成され、
    サーバーに提供するコードを有し、
    前記サーバーは、複数の知的エージェントであって、前記複数の知的エージェントの各知的エージェントは、前記複数の部品のうちの１つの部品と相互作用するように構成されており、
    前記各知的エージェントは、各基準に基づいて、前記部品からデータを受領するように構成され、
    前記複数の知的エージェントから処理されたデータを受領するように構成されている調整エージェントを有し、
    前記サーバーは臨時エージェントセットを有し、前記臨時エージェントセットは、レシピ管理を行うためのコードを有するように構成され、前記レシピ管理は、レシピの少なくとも１部分を、前記複数の知的エージェントおよび前記調整エージェントのうちの少なくとも１つに分配するためのコードを有することを含むことを特徴とする
    製造品。
11. 前記複数の知的エージェントの前記各知的エージェントは、前記複数の部品のうちの前記各部品のために、構成要件を規定するためのコードを有するための知能を有し、前記構成要件は、前記複数の知的エージェントの前記各知的エージェントに、データファイルを送るための基準を含み、前記基準は、前記複数の知的エージェントの前記各知的エージェントで局所的に保存された前記レシピの前記１部分に基づいている請求項１０に記載の製造品。
12. 前記複数の知的エージェントの前記各知的エージェントはキャッシュを有し、前記キャッシュが、データラッチを可能にするために少なくとも最新のデータファイルを保存するためのコードを有するように構成されている請求項１１に記載の製造品。
13. 前記複数の知的エージェントの前記各知的エージェントは、シグネチャデータを生成するために、前記データファイルのデータ分析を行うためのコードを有し、前記シグネチャデータは、前記データファイル用の要約データである請求項１２に記載の製造品。
14. 前記調整エージェントは、前記複数の知的エージェントの各知的エージェントから、シグネチャデータを受領するためのコードを有するように構成され、前記シグネチャデータは、前記データファイルの要約データである請求項１３に記載の製造品。
15. 前記調整エージェントは、複合的なシグネチャを生成するためにデータ分析を行う知能を有し、前記調整エージェントは、前記シグネチャデータを用いて、前記複数の部品に指示をするためのコードを有する請求項１４に記載の製造品。
16. 前記サーバーは、前記プラズマ処理システムに対する変更を特定するために自己発見を行う知能を有し、前記自己発見は、前記複数の部品の１つの部品が前記プラズマ処理システムに接続されたかを特定するためのコードを有する請求項１０に記載の製造品。

Images