JP4928541B2 - 統計的に繰返し可能な応答時間を有する多用途半導体製造コントローラ - Google Patents

Description

本発明は、ツール・ホストがデータ収集、監視及び制御タスクを代行することができる、半導体製造のためのプロセスＩ／Ｏコントローラに関する。特に、本発明は、データ収集、監視、制御及び応答の１つ以上を実行して、統計的に繰返し可能な性能及び精度でツール・ホストからのコマンドに応答することができるプロセスＩ／Ｏコントローラに関する。説明される実施形態は、優先順位を付けられたリアルタイム・オペレーティング・システムを使用して、半導体製造ツール及びセンサに関連するツールからのデータ収集を制御する。選択されたレシピ・ステップの間の選択されたコマンド及びセンサ入力に対する統計的に繰返し可能な応答性が、ジッタを効果的に減少させる。

ムーアの法則は、漸減する価格でのコンピュータ・パワーの指数関数的成長を約束する。この処理パワーの動的成長は、半導体デバイスの製造が油の試堀のような冒険的な仕事となるであろうと思わせる。真実は正反対である。なぜなら製造バッチは非常に貴重であり、製造プロセスはほんの小さな誤りに対しても敏感であり、半導体デバイスの製造は保守的な仕事であるためである。新しい装置についてのサイクル及び標準の認定と、古い装置の修正が、延々と続き、要求が厳しい。製造に引き渡される前に、ほんの小さな変化でさえも広範に綿密に検査される。

半導体製造における工場によって用いられる重要なコンポーネントには、ツール（例えば、堆積チャンバ、反応器）、ツールを監視するセンサ（例えば、ＦＴＩＲセンサ、質量分析器、熱電対）、及び、ツール動作に関するセンサからのデータを格納し分析するホスト又は分散プロセッサがある。

従来のアプリケーションは、センサからデータをリスニングし、それをイーサネット上のＴＣＰ／ＩＰのような高速のエラー耐性のある技術を用いてホスト又は分散型プロセッサに提供する、透過的な方法を説明していた。従来のアプリケーションは、発明者であるＵｚｉ Ｌｅｖ−Ａｍｉ及びＹｏｓｓｅｆ Ｉｌａｎ Ｒｅｉｃｈの「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍｏｎｉｔｏｒｉｎｇ Ｈｏｓｔ ｔｏ Ｔｏｏｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ」と題する２００１年８月２２日に出願された米国特許出願第０９／９３５，２１３号であった。従来のアプリケーションは、光学的に分離されたコネクタを用いてツール又はセンサからのシリアル通信を盗聴することができるリスニング・ポストを説明している。盗聴手法を用いると、工場通信及びデータ収集インフラストラクチャが、ツール又はセンサの修正を必要とすることなく、低リスクでアップグレード可能であることを証明することができる。アップグレードの実現可能性は、現在の通信インフラストラクチャを解体することなく実証することができる。

工場器械及びバックエンド分析の可能性の次の革命は、センサの分析特性を置き換える又は変化させることなく、プロセスＩ／Ｏコントローラの一方の側のツール及びセンサと他方の側のツール・ホスト又は分散型プロセッサとの間の通信を仲介するために、プロセスＩ／Ｏコントローラのようなインテリジェント・コントローラを付加することに関係する。増加したプロセッサ・パワー及び減少したストレージ・コストは、工場環境ではこれまで実際的でなかった構成のための機会を生み出す。発明者のＵｚｉ Ｌｅｖ−Ａｍｉ、Ｇｕｅｎｔｅｒ Ｓｉｆｎａｔｓｃｈ及びＭａｒｋ Ａｔｔｗｏｏｄｎｉｙｏｒｕによる第２の従来のアプリケーションである「Ｃｏｎｔｒｏｌｌｅｒ ａｎｄ Ｍｅｔｈｏｄ ｔｏ Ｍｅｄｉａｔｅ Ｄａｔａ Ｃｏｌｌｅｃｔｉｏｎ ｆｒｏｍ Ｓｍａｒｔ Ｓｅｎｓｏｒｓ ｆｏｒ Ｆａｂ Ａｐｐｌｉｃａｔｉｏｎｓ」と題する２００４年４月７日に出願された米国特許出願第１０／８１９，９０３号は、種々の可能性を有するインテリジェント・コントローラを説明している。説明したインテリジェント・コントローラの不足点は、統計的に繰返し可能な応答性を与えながら、ツール・ホストと協働して種々の機能を同時に実行する能力である。コマンドの開始時又は完了時のジッタは、現在のソフトウェア・アーキテクチャでは良好に制御されない。

ツール・ホスト又は分散型プロセッサからプロセスＩ／Ｏコントローラにデータ収集及び重要な制御を委ねることによって、プロセス・チャンバに適用される制御モデルを変化させる機会が生じる。さらに良いことに、統計的に繰返し可能な応答性を有する、より簡単に構成され、制御され、より回復力のあるコンポーネント及びシステムが、結果として得られる。

本発明は、ツール・ホストがデータ収集、監視及び制御タスクを代行することができる、半導体製造のためのプロセスＩ／Ｏコントローラに関する。特に、本発明は、データ収集、監視、制御及び応答の１つ以上を実行して、統計的に繰返し可能な性能及び精度でツール・ホストからのコマンドに応答することができるプロセスＩ／Ｏコントローラに関する。説明される実施形態は、優先順位を付けられたリアルタイム・オペレーティング・システムを使用して、半導体製造ツール及びセンサに関連するツールからのデータ・コレクションを制御する。選択されたレシピ・ステップの間の、選択されたコマンド及びセンサ入力に対する統計的に繰返し可能な応答性が、ジッタを効果的に減少させる。本発明の特定の態様は、特許請求の範囲、明細書、及び図面において説明される。

以下の詳細な説明は、図面を参照しながらなされる。好ましい実施形態は、本発明を解説するために説明されるのであって、請求項によって定められるその範囲を制限するためにではない。以下の詳細な説明への種々の均等な変化が、当業者であればわかるであろう。

緒言
歴史的に、工場においては、ホスト・システムは、メインフレーム、小型コンピュータ又はワークステーション上で動作する。ホスト・システムは、典型的に、工場における全ての又は多くの組のツールを制御し及び監視するモノリシックのものであった。ホスト・システムは、ツール及びセンサとインターフェースするためのアダプタに頼っていた。ホスト・システムは、典型的に、ツール及びセンサからデータを受信し、ツールに制御命令を発行するものであった。ホスト・システムは、しばしば、大量のシリアル通信メッセージを受信し、生成していた。

ツール・ホストという用語は、ツール制御ホストと、より制限された又は融通性のある分散型プロセッサとの両方を含むように、幅広い意味で用いられる。ツール・ホストは、包括的な集積されたツール制御機能をもつホストと、より制限されたタスク固有の機能をもつ分散型プロセッサ上で動作するホストとの両方を含む。ツール・ホストは、顧客固有のビジネス・プロセスの集中定義によって作動される単一の包括的製造所管理システムを提供するものとして説明される、ＣｏｎｓｉｌｉｕｍのＦＡＢ３００（ＴＭ）ソフトウェアといった製品を含む。このカテゴリのツール・ホストは、異なるベンダによって提供されたツールを制御するように設計された従来の製造実行システムに取って代わるように設計される。従来の製造実行システムからのツール・ホスト・スペクトルの反対端では、包括的管理システムとなることを要求することなく、種々の固有の機能を取り扱うために、分散型プロセッサ上でコンポーネント・プロセスを実行することができる。スペクトルに沿って、ＣｏｎｓｉｌｉｕｍのＦＡＢ３００（ＴＭ）ソフトウェアといった製品は、幾つかの目的のためのツール制御ホスト及び他の目的のための分散型プロセッサ上で実行されるプロセスと考えてもよい。

プロセスＩ／Ｏコントローラ
ここで開示される手法は、プロセスＩ／Ｏコントローラを使用する。プロセスＩ／Ｏコントローラは、プロセス・チャンバ又は他の半導体製造プロセス・デバイスを制御する信号を送信し及び受信する。
プロセスＩ／Ｏコントローラは、センサから収集されたデータをデータ・ユーザに通信する。データ・ユーザは、メインフレーム上で動作する従来のツール・ホストであってもよいし、分散型プロセッサ上で動作する新しいソフトウェアであってもよい。データ・ユーザは、モノリシック・システム、又は、独立して又は協働して動作する連合したパッケージであってもよい。プロセスＩ／Ｏコントローラはまた、センサからのデータを監視し、関心ある事象を識別し、既に収集されたさらなるデータを要求し、又は監視されたデータに応答してセンサのための収集プランを変更することができる。

１つの動作環境
図１は、本発明の態様が特に有用な環境を示す。これは、プロセス・チャンバ１２５、プロセス・チャンバとの間の種々の入力及び出力、それに加えて、センサ、制御チャネル及びコントローラを示す。チャンバ１２５は、堆積、クリーニング、エッチング、注入、灰化などのような種々の反応のために用いられてもよい。この図面には示されていない他のタイプのツールもまた、本発明の態様から有益である。
インターネットを介して潜在的にアクセス可能な工場ネットワーク１１１、仮想プライベート・ネットワーク又は広域ネットワーク１１２は、コントローラ、ファイアウォール、又は他のコネクタ１６２を通るツール・ネットワーク１１２への制御されたアクセスを有する。この図面におけるツール・ネットワークは、プロセス・チャンバ１２５に影響を及ぼす制御部及びセンサをリングに接続するように示されている。このアーキテクチャは単なる例示であり、工場においてはリングよりもシリアル通信、イーサネット、又は層状通信が用いられる可能性が高いことを当業者であれば理解するであろう。

反応チャンバ１２５へのガス入力は、ガス・ボックス圧力トランスデューサ１１３及び質量流量コントローラ（ＭＦＣ）１１４を通過するガスを含む。幾らかのガスは、オゾン発生器１３３を通過することができる。他のガス及びガス混合物は、反応性ガス発生器１１５及びガス組成モニタ１１７を通過することができる。反応性ガス発生器１１５は、プロセス・チャンバ１２５の内部又は外部のいずれかでプラズマを発生させることができる。ガス組成モニタ１１７は、反応性ガス発生器と直列であってもよいし、並列であってもよい。質量流量コントローラ１１４は、反応性ガス発生器１１５及びガス組成モニタ１１７とガス連通し、最終的に又は直接にプロセス・チャンバ１２５とガス連通する。ガス入力デバイス１１３、１１４、１３３、１１５及び１１７は、１つ又はそれ以上のデジタル・コントローラ１４２、チャンバ・コントローラ１５２及び接続点１６２と連通する。この連通は、典型的に制御と遠隔計測との両方を含む。これらのデバイスは、デバイスの動作又はガス入力及び／又は出力のいずれかに応答する制御部とセンサとの両方を含むことができる。

他の入力は、材料供給部１３４、冷却サブシステム１４５、及び種々のパワー・インジェクタ１５３、１５４及び１５５を含むことができる。反応チャンバ１２５は、堆積チャンバ、エッチング装置、熱プロセッサ又は他のタイプのリアクタであってもよい。反応チャンバは、幾つかの反応器に接続された自動処理セルであってもよい。反応チャンバの形式に応じて、材料供給システム１３４は、例えば、加工片１３６上に堆積するための材料を供給することができる。ほとんどの化学反応は温度に敏感な速度で進むことになるため、冷却サブシステム１４５は、チャンバ１２５内の温度を調整する一助となることができる。チャンバに供給される電力は、マイクロ−ワット電力１５３、プラズマを発生させるのに用いられるＲＦ電力１５４、及び、プラズマを発生させてチャンバ又はチャンバに供給されるガス又は他の材料を加熱するのに用いられるＤＣ電力１５５を含むことができる。ガス入力のような他の入力は、１つ又はそれ以上のデジタル・コントローラ１４２、チャンバ・コントローラ１５２及び接続点１６２と連通する。この連通は、典型的に制御と遠隔計測との両方を含む。これらのデバイスは、デバイスの動作を制御し又はそれらの入力及び／又は出力を感知するように応答する制御部とセンサとの両方を含むことができる。

センサは、チャンバ条件に応答するか又はチャンバからの排気に対して作用することができる。チャンバ条件に応答するセンサは、ウィンドウ１２６を通してチャンバ１２５の中を見て、フィルム厚さ、パターン及び他の特性（例えばＥＰＩ−オンライン（ＴＭ））を見るためのウェハ・モニタ１１６、エッチ・プロセス制御のための、干渉フィルタ又は干渉計を有する発光分光モニタといったプロセス・モニタ１２７、及び、圧力トランスデューサ１３７を含むことができる。チャンバ１２５からの排気に対して作用するセンサは、リーク検出器１４６、真空ゲージ１５７、及び排気モニタ１５８を含む。これらのセンサは、圧力コントローラ１４８及び制御弁１４７、並びに、真空コンポーネント及び／又はサブシステム１５６と相互作用することができる。それらはまた、図面には示されていないポンプ及び／又は排気ガス・スクラバと相互作用することができる。これらのセンサは、１つ又はそれ以上のデジタル・コントローラ１４２、チャンバ・コントローラ１５２及び接続点１６２と連通する。この連通は、典型的に、制御と遠隔計測との両方を含む。センサ、例えば１４７、１４８及び１５６と連通するデバイスは、制御部とセンサとの両方を含むことができる。

監視及び制御システムの望ましい特性は、その決定論、すなわち、全てのコマンドが指定されたデッド・ライン内で開始され又は完了されることになる信頼度である。幾つかのコマンドは、５分間に各々１００ミリ秒のサンプルを収集することなどを完了するのに多くの時間を要するため、開始と完了との両方が考えられる。指定された応答時間内にコマンドが開始され又は完了する確率として、決定論が定量化されることになる。決定論をテストするために、少なくとも１００万のコマンドが実行されることになり、それらの実際の応答時間は、ヒストグラム・テーブルに照合されることになる。コマンドの応答時間の少なくとも９９％が要求されたデッド・ライン内に含まれることが望ましい。さらに、専用テスト・イニシエータ（制御部を作動させるコンピュータ）上での専用ネットワークを介して数時間にわたり連続して作動されるテストについては、コマンドが指定された（例えば５、３又は１ミリ秒）時間内に実行される確率は、可能な限り多くの「ナイン」に達することが望ましいが、少なくとも９９．９９％、すなわち、１０，０００コマンドに１つが、指定された応答時間よりも長く遅延されるか、又は全く実行されないことを許容する。

いずれの通信技術も、デジタル情報を壊すか又はそうでなければその宛先に送るのに失敗する固有の能力を有する。これは、アナログ（電気）ドメイン及びデジタル・ドメインの両方における幾つかの現象による。結果として、１００％の決定論は、実現不可能な理想であり、実施はそれらがどれだけその理想に近づくことができるかによって評価される。これらの基準は、いわゆる「ナイン」か又は３シグマ又は５シグマ性能のいずれかとして表すことができる。シグマは、統計的測定である標準偏差と呼ばれる。

図２Ａ−図２Ｂは、性能及び分布としての分散統計値を示す。片側分布がカーブ２１０によって示されている。切り取り線２１１によって示される、３（３σ）又は５（５σ）シグマ、すなわち、∝＝０．０１（２ナイン）又は∝＝０．０００１（４ナイン）といった性能基準が設定される。応答時間の分布は、例えば、実際の応答時間の９９％が切り取り線２１１の左に入る場合に、基準に適合する。両側分布は、カーブ２２０によって示される。目標時間２２３の傍にある切り取り線２２２、２２４によって示される、３（３σ）又は５（５σ）シグマ、すなわち、∝＝０．０１（２ナイン）又は∝＝０．０００１（４ナイン）といった交差基準が設定される。目標時間からの分散分布は、例えば、実時間と目標時間との間の差の９９％が切断線２２２、２２４の間に入る場合に、基準に適合する。図示された分布は正規分布であるが、傾斜分布を含む他の分布を測定して、標準統計又はノンパラメトリック基準を適用することができる。これらの基準は、それらがシステムをオーバーロードしないようにするのに十分なだけ離間された刺激に適用される。例えば、プロセスＩ／Ｏコントローラのカードケージの実施形態は、全てのＩ／Ｏコマンドについて、こうしたコマンドが少なくとも２０ミリ秒の間隔で受信されたときに、５ミリ秒以内に実行されるように測定される。この応答時間についての制限要因は、カード・ケージ・シャーシに用いられるシリアルＣＡＮバス・バックプレーン及びサポートされたＩ／Ｏカードに内部的に用いられる他のシリアル・プロトコルであった。カスタム集積処理装置は、コマンドの頻度を制限することなく、全てのＩ／Ｏコマンドについて３ミリ秒以下で又は１ミリ秒以下でコマンドを実行することが予想される。

経験から、カード・ケージ・シャーシを用いて５ミリ秒の基準に適合するようにジッタが減少され性能が増加されることが判断される。３ミリ秒又は１ミリ秒といった、より厳格な公差に適合するためには、後述するように、より集積されカスタマイズされたハードウェア構成が必要であった。

（コントローラの配置及びアーキテクチャ）
図３は、ツール、センサ、及び、ツール・ホスト又は中央のマスターコントローラに結合された通信コーディネータのブロック図である。この通信コーディネータの構成は、２つのＳＥＣ／ＧＥＭインターフェース・ポート３１２、３１６と２つのネットワーク・インターフェース・ポート３３２、３３６とを含む。コントローラは、ＳＥＣＳ ＭＵＸ３１５を含むＳＥＣＳプロトコルを介して通信するために論理及びリソースを含む。コントローラはさらに、データ・ユーザと通信するための工場側インターフェース３３４と、ツール、センサ及び機器と通信するためのツール側インターフェース３３５とを実装する論理及びリソースを含む。ＳＥＣＳ ＭＵＸ３１５及びインターフェース３３４、３３５は、データ・コレクション及び出版リソース３２５に論理的に接続される。通信コーディネータの工場側では、従来のツール・ホスト３１１を、ＳＥＣＳ−Ｉ、ＨＳＭＳ又はＳＥＣＳのその後の改訂版又はＳＥＣＳへの後続版のいずれかであるＳＥＣＳ準拠通信チャネルを介して接続する３１２ことができる。本発明を適用しても良い非工場環境では、医療ツール又は数値制御工作ツールといった、監視されているツールと接続するために、他のプロトコルを用いることができる。ネットワーク３２２によって搬送されるＳＥＣＳとは別個の工場側プロトコルを介して、ストレージ３３１及び報告３２１リソースに接続することもできる。通信コーディネータのツール及びセンサ側では、ツール又はツール・クラスタへのＳＥＣ／ＧＥＭツール・インターフェース３１７を接続する３１６ことができる。コントローラはまた、センサ３２７、機器３３７及び潜在的にツール３１７を含む他のデバイスをホストするネットワーク３２６に接続する３３６ことができる。この図面は、ネットワークを介してセンサに接続されているコントローラを示すが、ＳＥＣＳ−Ｉ又はセンサに接続するための別のシリアル・ベースのプロトコルを代替的に用いることができる。図３を紹介すると、プロセスＩ／Ｏコントローラは、ツール・インターフェース３１６と機器インターフェース３３６との両方を取り扱うために導入されてもよい。プロセスＩ／Ｏコントローラは、通信コーディネータと置換されてもよい。

図４は、ツール、センサ及びツール・ホストと通信するために単一型の通信チャネルを用いる通信コーディネータのブロック図である。図５は、多数型の通信チャネルを用いることを示す。図４には、ＳＥＣＳの優越したシナリオが示されている。通信コーディネータ４０３は、ＳＥＣＳプロトコル４０７、４０９を使用してツール４０１とセンサ４０２との両方と通信する。ツール４０１とセンサ４０２との間の接続４０８は、図１の説明において識別された知覚のいずれかを含む、通常感知されるいずれかのタイプのエネルギー又は力に関係する。図５には、ＳＥＣＳとネットワーク通信との、より複雑な組み合わせが示されている。このシナリオにおけるＳＥＣＳ通信チャネル４０７のみが、通信コーディネータ４０３とホスト４０１との間にある。ツール側ネットワーク５０９は、通信コーディネータをセンサ４０２Ａ−Ｂ、管理されたスイッチ５１３、及びネットワーク付属ストレージ（ＮＡＳ）５１５に接続する。工場側ネットワーク５１９は、通信コーディネータ４０３を、従来のツール・ホスト又は分散プロセッサといった分析ソフトウェア５２３に、インターネット、ＶＰＮ又は専用内部ネットワークといった拡張ネットワーク５２５に、及び、通信コーディネータによって公開されたデータを存続させ又は格納するデータベース５２７に接続する。もう１つの方法として、データベース５２７は、通信コーディネータ４０３上に常駐することができる。もう１つの物理的実装が、後のセクションで説明される。図４においては、プロセスＩ／Ｏコントローラは、通信コーディネータ４０３がＳＥＣＳプロトコル・メッセージを取り扱う状態のまま、通信コーディネータ４０３とツール及びセンサ４０７、４０９との間に導入される。図５においては、プロセスＩ／Ｏコントローラは、通信コーディネータ４０３とツール及びセンサ４０１、４０２との間に導入される。もう１つの方法として、ＳＥＣＳプロトコル、管理されたスイッチ５１３及びＮＡＳ５１５を無くすことで、プロセスＩ／Ｏコントローラは、通信コーディネータ４０３と置き換えることができる。

（カードケース実施形態）
第１のプロセスＩ／Ｏコントローラの実装は、前の製品に用いられた３Ｕ「ユーロ・カード」形状因子に基づくものである。それは、ＣＡＮバス上で単純化された高性能プロトコルを用いるように修正されている既存の離散型アナログＩ／Ｏカードを再使用する。２つのイーサネット・ポート（レイヤ２スイッチ・ファブリックに相互接続された）を実装し、プロセスＩ／Ｏコントローラ・ソフトウェア要素をサポートする、付加的な３Ｕカードが付加される。一実施形態においては、それは実際のＩ／Ｏ点にアクセスするためにＣＡＮバス上の専有プロトコルを使用する。この実装はモジュラであり、単一のカードケージに１６までのＩ／Ｏカードをサポートする。システムは、利用可能なカードスロット毎にどのＩ／Ｏカードがインストールされたかを自動的に検出し、自動的に検出された構成を反映するように全てのソフトウェア要素（制御及びデータ・コレクション）を構成する。

図６は、プロセスＩ／Ｏコントローラの物理的アーキテクチャの高レベル・ブロック図である。この実施形態においては、ＳＣＡＮバス６２１は、カードケージにおけるカードをインターフェース・コントローラ６３１に接続する。インターフェース・コントローラは、Ｍｏｔｏｒｏｌａ Ｃｏｌｄｆｉｒｅ３２ビット・プロセッサ、インターネット接続性（前側６４２及び後側６４３）、ＲＳ２３２及びＲＳ４８５サポート間のソフトウェア選択を有する１つ又はそれ以上のＵＡＲＴ、及び、プラグ・アンド・プレイＩ／Ｏのための内部ＣＡＮバス・コントローラを有するＮｅｔｃｏｍカードであってもよい。イーサネット・コネクタは、制御機能と他の機能との間で優先順位をつけることができる。カードは、デュアル・スロット用に構成された、３６−６８リレーと８−３２ＤＩＤＯチャネルを有するＭＫＳ機器ＣＤＮ４９７−Ｃ−Ｅといったインターロック・カード６１１を含むことができる。アクティブなインターロックは、インターロック・カード上のステータス・ライトによって示される。それらは、アクティブ低信号を用いて動作する４８入力／出力点を有するＭＫＳ機器ＣＤＮ４９１−Ｃ−Ｅ及び１２ビット・コンバータに結合された３２アナログ入力及び１６アナログ出力を有するＭＫＳ機器ＣＤＮ４９６−Ｃ−ＥといったデジタルＩ／Ｏ６１２及びアナログＩ／Ｏ６１３カードを含むことができる。

このモジュラ設計は、低体積用途に最良に適合する。それは、既存のＩＯカードを再使用し、用途の要件に従ってカスタム・シャーシ及び分布パネルの開発のみを必要とすることによって、開発コストを節約する。単位当たり価格に基づくと、モジュラ設計は、十分にカスタマイズされたモノリシック実装よりも高価である。しかしながら、それは、所望の高速応答時間及び狭い公差を与えるものではない。

（カスタム、モノリシック実施形態）
遠隔Ｉ／Ｏユニットは、大きなカスタム・バージョンで提供されるときには、より競争力のある価格がつけられたものとすることができる。モジュール性を無くすと、ハードウェア・コンポーネントのコストが大きく減少することになる。カードケージの実施形態から、シリアル・バックプレーン（ＣＡＮバスに基づく）は、性能に対して負の影響を有することが学習された。この理由のため、全てのＩ／Ｏ信号は、性能を改善するためにパラレル・バックプレーン、データ・バスを介してプロセッサに接続される。

（単一のファームウェア、多数のハードウェア）
ハードウェアのモジュール性（カード、スロット、コネクタ）の除去は、論理的モジュール性の除去を必要としない。全てのＩ／Ｏを「論理カード」に何か似ているものにグループ化することによって、メイン・コントローラ・ファームウェアは、ハードウェアに存在するＩ／Ｏ信号のタイプ及びカウントを動的に発見し、この構成に従って全てのソフトウェア・オブジェクト・マッピングを実行するように作ることができる。これは、異なるハードウェア実施形態を実行することができる単一バージョンのファームウェアを生み出す。他の多くの論理的に似ているが物理的に別個のユニットで新しい機能部及びバグフィックスが利用可能であり、コストが削減される。

図７は、ＭＯＤＢＵＳ／ＴＣＰインターフェースを有するＩ／Ｏ及びＣＯＭアーキテクチャのブロック図である。リアルタイム制御部７１１が、Ｉ／Ｏドライバ７３１（例えばＳＣＡＮバスを介して）、ＭＯＤＢＵＳ ＴＣＰドライバ７３３、データ・ロガー７１２及び診断部７１３に結合される。Ｉ／Ｏドライバ７３１は、ＣＡＮ Ｉ／ＯチャネルのようなＩ／Ｏチャネル７４１に結合することができる。この図に示されているタスクには、プリエンプティブ優先度に基づくスケジューリングを有するリアルタイム組み込みオペレーティング・システムを用いて確定的動作のための高い優先度が割り当てられることになり、時間のかかる、しかも重要でない処理タスクのための残りの処理リソースの使用に沿って、より低い優先度の他のタスクが残る。タスク７１３、７２４及び７３４は、重い処理要求を有する低優先度のタスクである。データ・ロガーは、データ・コレクション７２３及びユーザ・インターフェース７２４に結合される。データ・コレクションとユーザ・インターフェースとの両方は、ＴＣＰ／ＩＰ７４３及びイーサネット７５３上のＨＴＴＰサーバ７３４を通じてアクセス可能である。データ・ロガー７１２はまた、ゲートウェイ７３２及びＵＡＲＴ７４２を介して又はＴＣＰ／ＩＰ７４３及びイーサネット７５３を介してメッセージを搬送することができるＭＯＤＢＵＳ ＴＣＰ７３３リソースに結合される。

（一般特性）
両方のハードウェア実施形態は、事実上の標準ＭＯＤＢＵＳ／ＴＣＰを用いてＩ／Ｏ信号へのアクセスを提供することができる。もう１つの方法として、僅かに速い応答時間が要求される場合に、低品位のＵＤＰプロトコルによるＭＯＤＢＵＳの独自の実装を用いることができる。ＭＯＤＢＵＳ仕様はオープンであり、自由に入手できるため、ＭＯＤＢＵＳの選択は、新しい、並びに、既存の半導体製造プロセス制御装置へのプロセスＩ／Ｏコントローラの高速の安価な統合を可能にする。制御ソフトウェアの統合のための参照コードとして多数のＭＯＤＢＵＳ実装が利用可能である。

図８は、プロセスＩ／Ｏコントローラ８２０、８３０をツール・ホスト８１０に関連させる高レベル・ブロック図である。ツール・ホスト８１０は、制御プログラム８１１、ＭＯＤＢＵＳ／ＴＣＰマスター・アプリケーション・プログラム・インターフェース８１２及びウェブ・ブラウザ８１３を含む。プロセスＩ／Ｏコントローラ８２０は、ＭＯＤＢＵＳ／ＴＣＰインターフェース８２１及びウェブ・サーバ８２２を含む。ＭＯＤＢＵＳ／ＴＣＰインターフェースは、負荷及びＪａｖａＳｃｒｉｐｔルーチン８２３の実行を制御し、Ｉ／Ｏインターフェース・ピン８２５への直接アクセスを与える。ウェブ・サーバ８２２は、データ・コレクション８２４へのアクセスを与える。付加的なプロセスＩ／Ｏコントローラ８３０は、８２０と同じ能力を有する。イーサネット８１５を介する通信は、ツール・ホストをプロセスＩ／Ｏコントローラに接続することができ、又は、プロセスＩ／Ｏコントローラ８２０、８３０を相互接続することができる。

プロセスＩ／Ｏコントローラの実施形態は、効率的及び確定的な組み込まれたリアルタイム・ソフトウェア・プラットフォームを用いて、ＤｅｖｉｃｅＮｅｔを含む従来の産業ネットワークの性能及び決定論を効果的に上回り、それにより、制御システムを乗り換えることに関係するリスクを低減させる。以下は、これらのＭＯＤＢＵＳ遠隔Ｉ／Ｏ制御のプロセスＩ／Ｏコントローラの実装によって与えられる幾つかの特徴である。

最下位レベルにおいて、特定のアプリケーション固有のリレー回路又はインターロックは、加工機械が潜在的に危険な状態に入るのを防止するように設計される。この方法は、特注のプロセス制御固有Ｉ／Ｏサブシステム設計を必要とする主要なファクタの１つである、いずれかの半導体プロセス制御アプリケーションの一部として伝統的に用いられている。これらのインターロックは、論理ソフトウェア・エラー、又は、ガス及び／又はエネルギー・レベルの潜在的に危険な組み合わせをトリガしうるその他の不測の事態から防護する。幾つかのプロセスＩ／Ｏコントローラ実施形態製品は、カスタム又は準カスタム・リレー又はインターロック回路、及び、ネットワーク接続を介してこれらのリレーを監視することを可能にする付加的な電子装置を含むことになる。

第２レベルにおいて、コントローラＩ／Ｏデバイスは、その組み込まれたファームウェアの故障から内面的に防護する。Ｉ／Ｏ信号は、プロセスＩ／Ｏコントローラのファームウェアが所定の時間間隔でＩ／Ｏ回路に「鼓動」パルスを与えないように全ての別個の出力をオフにすることになる、プログラム可能論理アレイ（例えばＣＰＬＤ）によってハードウェア制御される。同様に、アナログ出力は、ファームウェアが故障したようである場合には、０ボルト・レベルにリセットされることになる。これらの出力ステータス、個別の出力のためのオフ状態、及びアナログのための０ボルトは、半導体プロセス装置制御システムにおけるセーフ出力ステータスとして伝統的に指定されている。

最高位レベルにおいて、ファームウェア構造部は、出力をアクティブに維持し、プロセスＩ／Ｏコントローラが所定の規則的な頻度でＭＯＤＢＵＳコマンドを発行し続ける限り鼓動パルスを保つ。プロセス制御論理を動作させるメイン・コンピュータが故障した場合には、プロセスＩ／Ｏコントローラのファームウェアは、ツール・ホストが動作を再開するまで、全ての出力をセーフ状態にすぐに変えることになる。この構造部は、その動作モードを診断に切り替えることによって、プロセスＩ／Ｏコントローラ製品において潜在的にディスエーブルにされてもよい。診断、又はその他の高レベルのデバッグ動作モードが選択されたときにはいつでも、プロセスＩ／Ｏコントローラ・ユニットは、そのフロント・パネル上のステータス・ライトを黄色又は琥珀色（通常の緑色表示ではなく）に落とすことによって、それをはっきりと示すことになる。

（診断ツール）
これらのプロセスＩ／Ｏコントローラは、遠隔Ｉ／Ｏユニットのためのウェブ・インターフェースを与える。インターネット・ブラウザを装備したパーソナル・コンピュータは、様々な必要性のためにＩ／Ｏユニット・ユーザ・インターフェースに直接アクセスするために用いることができる。このユーザ・ウェブ・インターフェースは、プロセスＩ／Ｏコントローラによって与えられた通常のＭＯＤＢＵＳ制御サービスを補うものであり、プロセス装置の配置、製造及び保守の間に用いるために利用可能である。配置の間に、組み込まれたウェブ・ユーザ・インターフェースは、アプリケーション固有のソフトウェアが十分に配置されテストされるまで待つ必要なく、エンジニアが彼らのプロセス装置を構築しテストすることを可能にする。

ウェブ・インターフェースは、プロセス制御ソフトウェアが低レベル診断インターフェースを露出する必要性をなくし、技術者が入力を監視し、最下位レベルで出力を実行することを可能にする。製造試験の必要性は、ウェブ診断インターフェースによって満たすことができる。保守トラブルシューティングについても同じであり、特別なソフトウェア又はハードウェアは必要ではなく、パーソナル・コンピュータを用いて、イーサネット・ポートを介してＩ／Ｏユニットに接続することができる。また、診断のためのウェブ・インターフェースが極めて直観的であり、事実上、特別な訓練なしに用いることができるため、現地保守要員の訓練の必要性が実質的に減少される。しかしながら、診断は、時々安全要件と対立することがある。したがって、診断ウェブ・インターフェースは、Ｉ／Ｏユニットが製造モードにあるときに、監視のみモードに減少されることになる。

製造モードにあるときに、プロセスＩ／Ｏコントローラ・ファームウェアは、ツール・ホストがアクティブである限り出力をアクティブ・オンリーに保ち、ツール・ホスト又はマスター或いは中央コントローラへの出力状態の排他的制御をなお維持し、フロント・パネル上のステータス・インジケータを緑色に明減させることによってこの状態を示すことにもなる、安全ウォッチドッグを使用可能にする。しかし、プロセスＩ／Ｏコントローラ・ファームウェアが診断モードに切り替えられた（例えば回転スイッチによって）ときには、安全ウォッチドッグが無効化することになって、ツール・ホストに対する要件がなくなり、ウェブ・ユーザ・インターフェースによる出力の制御が可能になり、この状態は、琥珀色のステータス・ライトの明減を用いて示される。

（デュアル・パーソナリティ−遠隔Ｉ／Ｏ及びデータ・コレクション）
プロセスＩ／Ｏコントローラ製品アーキテクチャの部分は、プロセス障害検出及び高度化されたプロセス制御の目的で、データ収集及び分析のためのＭＫＳ機器ＴＯＯＬｗｅｂ（登録商標）フレームワークをサポートする。ＴＯＯＬｗｅｂの成功は、できるだけ多くの変数について収集することができる高品質データを使用する。ＴＯＯＬｗｅｂ ＴｏｏｌＳｉｄｅプロトコルと組み合わされたデータ収集エージェントのプロセスＩ／Ｏコントローラの実装は、事実上、そのＩ／Ｏ信号の全てを高頻度で収集するために利用可能にする。したがって、説明された構造部を具現化するプロセスＩ／Ｏコントローラは、ＴＯＯＬｗｅｂデータを集め、下位のプロセスの包括的分析のための機会を生み出す。
現在のプロセス制御ソフトウェア・データ・コレクション実装は、洗練された数学的モデリング方法によって必要とされる品質及びスループットがしばしば欠如していることを経験が証明している。現在の制御ソフトウェアは、主にプロセスを制御することが意図されており、そのため、制御に不可欠ではないものはどれも実施者の優先度リストにおいて下位になる傾向があり、実施される場合には典型的に不十分である。

サンプリング
半導体製造プロセスを監視するセンサは、プロセスを制御し、特定の重要なプロセス・パラメータを割り当てられた公差内に維持するために用いられる。さらに、ウェハが完成された後で、欠陥分析のためにデータを収集し、格納し、分析することが、ますます一般的になってきている。処理チャンバに接続されたセンサからの読取は、オフライン分析のために収集され格納され、それはプロセス障害の根本的原因を見つけ出すために種々のデータ・ソースの相関をとること、又は、プロセス装置に対して要求される予防保守を予測することを目的としている。センサは典型的に、種々のガス圧センサ、温度トランスデューサ、マスフロー・コントローラ、ＲＦ及びＤＣ電力源及びエネルギー伝達機器などを含む。
収集されたデータは、その後の数学的又は統計的分析を可能にする品質のものであるべきである。測定機器は、根本的な物理量の正確なデジタル読取をもたらすべきである。測定サンプルは、プロセス量のいずれの期待変化率よりも著しく短い時間間隔でとられるべきであり、それにより変化率又はその他の変化率又はパターンにおける異常が、採用されるいずれかの分析法によって容易に示される。サンプルは、指定された統計的に繰返し可能な時間間隔でとられるべきである。

機器が各々の測定を行うときの時間が、値、すなわちサンプル時間を導出することができる少なくともサンプル番号と共に記録されるべきである。この収集されたデータのタイムスタンプは、特にサンプルのタイミングにおけるジッタが存在する場合に、その値と同様に重要である。記録され又は導出された融解は、少なくとも測定と同様に正確であるべきであり、そうでなければ、変数の導関数を計算するのに実用可能ではないであろう。物理的測定の導関数は、所与の測定の変化率又は「傾き」を反映し、種々のプロセス異常を検出する又は予防保守の必要性を効果的に予想するのに重要な役割を果たすことができる。例えば、温度の傾きが正である場合の、チャンバのウォームアップ相の間の温度導関数の漸落は、加熱源の漸進的疲労の指標であり、この量におけるいずれの大きな突然の降下も、使用された加熱源の１つが故障したことの確かな兆しである。温度導関数が負である場合に冷却すると、前の実行に対するこの量の低下は、冷却プロセスが速過ぎて、加工された材料、すなわちシリコン・ウェハの結晶構造体応力を増加させることになることを示すであろう。

データ取得からの制御の分離
センサ及び材料供給コントローラは、収集されたデータの品質に対してマイナスの影響を及ぼすことなく制御がデータ収集を優先させるように、リソース使用が厳しく優先順位をつけられる、進化したデータ収集を意図して開発されている。これは、データ収集タスクを残し、残りのリソースの使用を報告しながら、制御コマンド及び測定クエリへの統計的に繰返し可能な応答を保証するように応答可能なプリエンプティブ・スケジューリングを伴うリアルタイム・オペレーティング・システムに関係している。
それらの２つのアクティビティの要件のために、制御及びデータ収集について異なるプロトコルを使用することが有益となることがある。制御は、確定的応答時間及び効率に重点をおくが、データ収集は、低い複雑さと、ＩＴシステム及びデータベースとの統合の容易さを好む。異なるプロトコルの使用はまた、２つのアクティビティを増幅させるソフトウェア要素を区別する。幾つかのケースでは、これらのアクティビティの各々について個別のハードウェア・インターフェースを用いること、例えば、制御についてはＤｅｖｉｃｅＮｅｔ又はアナログ・インターフェースを、データ収集についてはＴＣＰ／ＩＰ及びＨＴＴＰ Ｗｅｂ技術を用いるＩＴフレンドリーなイーサネット・ポートを用いることも適切である。他の状況では、ＨＴＴＰ／ＸＭＬデータ収集プロトコルにも用いられる同じイーサネット・ポート上で、制御についてのＭＯＤＢＵＳ／ＴＣＰを実行することが非常に適切なこともある。

収集タイミング・デカップリング及びバッチ伝送
１つのデータ収集手法は、データ収集の正確なタイミングを保証するために装備されなければならないセンサに関するものである。「データ収集プラン」がセンサのファームウェアに導入される。したがって、データ収集クライアントは、軽量データ収集デーモンをトリガして、正確な間隔でデータのサンプリングを始め、タイムスタンプを有するデータ・サンプルを増加させ、サンプルを所定サイズの循環バッファに格納する、収集プランを定義する必要がある。
その後、データ収集クライアントは、特定の収集プランに関係するバッファされたサンプルを検索し、典型的には最後のデータ伝送からの記録された全てのサンプルを受け取るための周期的な要求を、リソース優先度の許しに応じて作成することになる。データ検索要求の間隔は、要求が循環バッファのオーバーフローを回避する間隔で作成される限り、正確又は確定的となる必要はない。データにはタイムスタンプが付随するため、データ検索のいずれの待ち時間も、収集されたデータの品質に対する影響をもたない。バッファがサンプルを数秒保持するのに十分なだけ大きい場合には、データ収集クライアント又は基礎となるネットワーク・インフラストラクチャの突発故障がない限り、データが失われないことがほぼ保証される。収集プランの定義において、データ収集クライアントは、どの測定値がいつどれくらいの頻度で収集されるかを定義する。十分なリソースを有するセンサは、多数のデータ・クライアント及び収集プランに適応することができる。

データ・サンプルは、随意的に、順序番号と共に増加する。データ収集クライアントは、データ・サンプルの重複記録を回避し、失われたデータ・サンプルを検出するために、順序番号を使用する。順序番号はまた、データ収集サーバのステートレス実装をサポートして、データ収集クライアントが検索された最後のデータ・サンプルの順序番号を追跡し、次の順序番号で始まるデータを要求することを可能にする。ステートレス・サーバの実装は、メモリ及びＣＰＵリソースの両方の使用において効果的となることが知られており、データを保存するためのセンサに関するリソース要件を減少させる。
データ・サンプルのセンサ・バッファの検索は、クライアントのデータ要求が、バッファにおけるサンプルの最大数までの多数のデータ・サンプルをサービスするように、本質的にバッチ化することができる。これは、多数のデータ・サンプルに対するデータ検索要求に関連するオーバーヘッドを広げて、データ収集プロセスをより帯域幅効率の良いものにし、被った平均オーバーヘッドを減少させる。

（センサ・プロトコルの実装）
サンプル・バッファリングを実装する種々の配置段階において幾つかのセンサ及び材料供給製品が存在する。それらは、ＨＴＴＰのステートレス・クライアント−サーバ実装に与えられる、ＸＭＬベースのデータ・モデルを使用する。センサはサーバを実装する。組み込まれたＨＴＴＰサーバは、構成及び診断のための機器にユーザ・インターフェースを直接提供する。ＸＭＬベースのコマンド及び応答のレパートリーは、データ・コレクションクライアントがネットワーク上でこれらのセンサを自動的に見つけ出し、収集のために利用可能な測定値（すなわち変数）の完全なリストを検索し、アプリケーション固有の収集プランを定義し、バッファされたデータ・サンプルを検索することを可能にする。
これらのセンサの幾つかは、制御のための別のインターフェースを使用し、それは幾つかのケースでは別の物理的ＤｅｖｉｃｅＮｅｔ接続を使用するが、他のものは、ＭＯＤＢＵＳ／ＴＣＰプロトコルと同じイーサネット・ポートを共有する。ＨＴＴＰデータ収集及びユーザ対話は、統計的に繰返し可能な性能又はタイミングの障害を引き起こさないことが実証された。

（優先順位付け）
プロセスＩ／Ｏコントローラの両方のパーソナリティ、すなわち、ハード・リアルタイム・トランザクション指向ネットワーク化Ｉ／Ｏ制御と収集されたデータの時間弾性公開を実装するために、これらのセンサは、進化したリアルタイム・ソフトウェア・ファウンデーションを特徴付ける。このファウンデーションによれば、両方のアプリケーションは、リソース使用への厳しい注意と、リソース割り当ての意識的な優先順位付けを伴って構築され、それにより、許可された性能パラメータ内のデータ収集アクティビティは、ＭＯＤＢＵＳ制御コマンド性能を低下させない。また、収集されたデータの公開は、期待されたＭＯＤＢＵＳアクティビティ・ボリュームのときに、量又は品質の損失もなしに収集されたデータを公開するのに十分な帯域幅が利用可能なままとなるように実施される。
優先順位付けに加えて、変数サンプルの総数及び収集頻度は、データ収集アクティビティがＭＯＤＢＵＳと組み合わされたときに、利用可能なリソースをオーバーランして、収集データを失わせ又は予測できないシステム挙動を引き起こさないように制限される。

（論理対物理的データ）
制御の目的のために、プロセスＩ／Ｏコントローラは、コネクタ・ピンの番号によってそのＩ／Ｏへの低レベル・アクセスを可能にし、値は、単純なバイナリ形式で表される。ツール・ホストは、変数に対するコネクタ・ピン番号のそれ独自のマッピングを行うことが期待されるが、ＣＯＮＴＲＯＬウェブは、生の値を保存し、性能を最大にするためにいずれの変換も行わない。
一方、分析のためには、データ要素は論理的意味を有するべきであり、すなわち、変数名は実際のパラメータを表すべきであり、アナログ値は測定値の物理的単位にスケール変更され又はオフセットされるべきである。値はセンサの校正のために補正されて、同様のプロセス・チャンバからセンサによって収集された値が比較に値するものとなるようにされるべきである。

コネクタ・ピンの象徴的表現を加えるために、これらのプロセスＩ／Ｏコントローラは、種々のマッピング・テーブルを実装し、それは設定可能であり、不揮発性メモリに保存され、関心あるＩ／Ｏ信号に論理名及び数値調節を割り当てる。幾つかのプロセスＩ／Ｏコントローラにおいては、Ｉ／Ｏピンのカウントは、マッピング・テーブルにおける象徴的変数の数を超えることに注意されたい。マップされたＩ／Ｏピンのみがアクセス可能である場合には、マッピング・テーブルはまた、データ収集及び分析についての関心あるＩ／Ｏ信号を識別する。
プロセスＩ／Ｏコントローラは、Ｉ／Ｏピンに取り付けられたセンサ及び制御部のために構成される。関心ある変数は、識別され名前付けされ、必要なときには、報告された値が好ましくは測定標準単位においてより意味のあるものとなるように、数値スケーリングオフセットが適用される。収集されたデータは記号により名前付けされるため、所与のツールのセットアップ及び機器の幾つかの詳細が利用可能である場合に、オフライン又はオフサイトがとられたときでさえも、その意味を認識することができる。収集された値は、実際のツールがアップグレードされ又は更新されたときでさえも、それらの意味をある期間にわたって保持することができる。
同様のツール上にインストールされるプロセスＩ／Ｏコントローラを構成するときには、構成は、構成をテキストファイルにダウンロードし、テキストファイルを他のプロセスＩ／Ｏコントローラにアップロードする能力によって単純化される。これらの構成ファイルは、標準ＰＣソフトウェア・ツールを用いてオフラインで編集することができ、構成はプロセス専門家によってオフサイトで用意されることが可能となる。

（遠隔Ｉ／Ｏ知能、スクリプト記述）
カード・シャーシ・コントローラ・アーキテクチャの最初の目標は、イーサネット上のＭＯＤＢＵＳについての可能なだけ最速の応答時間を搾り出すことと、繰返し可能な制御精度をＤｅｖｉｃｅＮｅｔといった遅い工業バスを用いて達成可能な精度を上回るように改善することであった。本発明者らは、多くのケースにおいて、プロセスの精密なタイミングのネックは、ツール・ホスト又はマスター・コントローラ自体、及び、ツール・ホストを実装するために用いられるオペレーティング・システムにあることを学習した。幾つかの既存のマスター・コントローラは、５０ミリ秒の公差内で動作し、他のものは、１００ミリ秒の公差内で動作する。
実際には、これらの制御システムは非常に複雑であり、大きな設計チームによって長期間にわたって頻繁に開発される。使用される開発ツールは、多目的コンピューティング・プラットフォーム上でのみ利用可能である。これらのレガシー・ソフトウェア・システムの複雑さは、それらの不正確さに著しく寄与する。

ワークステーションを各々のプロセス・ツールに専用化することなくプロセス精度を改善するために、これらのプロセスＩ／Ｏコントローラは、遠隔Ｉ／Ｏを制御するために、制限された、それでもなおパワフルなプログラミング環境を実装する。このプログラミング環境は、従来のプロセス制御ソフトウェア・システムを置き換えることを意図されたものではなく、むしろ、ツール・ホスト又はマスターコントローラの制御の下で残る、リアルタイム・ベースのプロセスＩ／Ｏ制御ユニットに重要なタイミング要件を有するプロセス制御論理の部分を委ねることによって、それらを増大させることが意図されている。
ソフトウェア又はオペレータは、短い、それでもなお重要なプロセス・ステップを識別し、要求された監視及びフィードバックを、５ミリ秒より良好な、３ミリ秒より良好な、又は１ミリ秒より良好な精度といったタイミング精度で、リソース制限された確定的リアルタイム・オペレーティング環境内で実行することができる小さなプログラムに変換する。

言語、プログラミング・ツール
プロセスＩ／Ｏコントローラの局所的プログラミングは、オブジェクト指向イベント主導解釈済みプログラミング言語である、ＥＣＭＡ標準ＪａｖａＳｃｒｉｐｔ言語のサブセットをサポートする。プログラムは、プレーン・テキストでＩ／Ｏユニットにダウンロードされ、その後、ＭＯＤＢＵＳを介して設定し監視することができる特別に割り当てられたプログラム状態レジスタを用いて呼び出される。このプログラム状態レジスタはまた、プログラムの実行及び完了を監視するためにツール・ホストに対して用いられる。この環境を実装するのに適した１つのプロセッサ・ファミリーは、減少された命令セット計算（ＲＩＳＣ）マイクロプロセッサのＭｏｔｏｒｏｌａ ＣｏｌｄＦｉｒｅファミリーである。このファミリーにおけるマイクロプロセッサの１つは、ＭＣＦ５２８２と表される。これらのプロセッサは、ｖｅｎｅｒａｂｌｅ６８０００プロセッサ・シリーズから得られるため、多くの開発ツール及び種々のリアルタイム・オペレーティング・システムが利用可能である。このプロセッサ・ファミリーのブロック図及び詳細は、ｗｗｗ．ｆｒｅｅｓｃａｌｅ．ｃｏｍでアクセス可能である。

制限された数のスクリプト・プログラムがあらゆる所与の時点で実行されるべきであり、これらのプログラムはサイズが制限されるべきである。サイズ制限が導入され、特定の言語ツール又は機能部がこの実装から除去されて、ユーザ記述スクリプトが利用可能な計算リソースをオーバーランして制御サブシステムの未定義の挙動が引き起こされる恐れが最小になる。さらに、それは、プログラミング・エラーを通じて、スクリプト・インタープリタよりも低い優先度が割り当てられたプロセスＩ／Ｏコントローラの特定の部分を部分的に中断することを可能にすることができる。危険にさらされる機能部には、ウェブ・ユーザ・インターフェース、データ・コレクション、及び、他の並行スクリプトを実行する隣接するスクリプト・インタープリタがある。したがって、これらのユーザ・スクリプト・プログラムを短時間簡単に保持し、緊密なループを回避し、可能な限りどんな場合でもイベント通知を使用することが推奨される。

特別なウェブ・ページが、最近のスクリプト実行履歴を表示することになる。このウェブ・ページは、ＭＯＤＢＵＳを介して利用可能なプログラム・ステータス・レジスタよりも詳細を与える。
クラスの階層は、プロセスＩ／Ｏコントローラ上の局所Ｉ／Ｏ信号を表すように、スクリプト・インタープリタに組み込まれ、それにより、スクリプトは、出力に対する制御を実行し、入力を監視することができる。また、個別の入力は、特定のスクリプト機能に割り当てられ、これらの入力が値又は状態を変化させるときに非同期的に呼び出されるイベントを生成することができる。

仮想Ｉ／Ｏ、スクリプト制御及び監視
スクリプト・インタープリタには、対応するスクリプト・インタープリタのステータスを制御し監視するＭＯＤＢＵＳを介して読み取られ書き込まれることができる特別な１６ビット・レジスタが割り当てられる。マスター又は中央コントローラは、スクリプトの実行を開始し又は中止するようにこのレジスタに書き込み、又はインタープリタ・ステータスを監視するようにこのレジスタを読み取ることができ、すなわち、それはスクリプトが実行されている場合であり、或いは正常終了された場合、又は異常終了されている場合、その後者のケースでは、このレジスタは、スクリプト終了コードを含むことになる。
前述のプログラム制御レジスタはさらに一般化され、制限された数の付加的なレジスタが各々のスクリプト・インタープリタについて予め定義される。これらの付加的なレジスタは、プログラム・ステータス・レジスタと同様に、ＭＯＤＢＵＳを介した読取及び書き込みのためにアクセス可能であり、適切なインタープリタ上で動作するスクリプトによってもアクセス可能である。これらのレジスタは、ＣＯＮＴＲＯＬウェブ上で動作するスクリプトとマスター・コントローラとの間の通信に関係する種々の目的のために用いることができる。

遠隔Ｉ／Ｏ、分散スクリプト
局所Ｉ／Ｏ信号への十分な、妨害を受けないアクセスに加えて、スクリプト・インタープリタは、他のプロセスＩ／Ｏコントローラに物理的に接続されたＩ／Ｏ信号を表すように設定することができるクラス階層を用いて増補されるが、関連付けられた後では、同じ基本アクセス方法及び属性のときに、ほぼ局所Ｉ／Ｏ信号と同様に振舞うことになる。他のプロセスＩ／Ｏコントローラ（遠隔Ｉ／Ｏ動作）上に常駐するＩ／Ｏ信号は、典型的に、よりゆっくりと応答し、非同期イベントのためのソースとして用いることができない。
他のプロセスＩ／Ｏコントローラ上のこの遠隔Ｉ／Ｏは、同じネットワークに接続された他のプロセスＩ／Ｏコントローラ上のＩ／Ｏ信号へのアクセスを与えるＭＯＤＢＵＳクライアント（マスター）実装をスクリプト・インタープリタに増補することによって実装される。
この便利な機能は、前述の制限を考慮して用いられるべきである。最良の用途の１つは、単一のプロセス・シーケンスを実行するように組み合わされる、異なるプロセスＩ／Ｏコントローラ上で同時に動作するスクリプトを同期することであり、Ｉ／Ｏカウント及び／又はプロセス物理レイアウトは、全ての関連するＩ／Ｏ信号を同じプロセスＩ／Ｏコントローラに接続する非現実的なものである。

プロセス・レシピ代行
製造プロセスの詳細は典型的に「レシピ」と呼ばれ、それは実際には、化学的又はセクション・プロセスのシーケンス、タイミング及び閾値を含む詳細を支配するプログラムである。幾つかの従来のプロセッサでは、レシピは、製造所制御ホストによって、チャンバ・プロセス制御コンピュータにダウンロードされる（又は前に保存されたレシピが選択される）。このレシピは、その後、ロットにおける全ての単一ウェハについてマスター・コントローラによって実行される。マスター・コントローラの目的は、所与のロットにおける全ての単一ウェハについて、又はその他のロットについてできるだけ正確にこのレシピを繰り返して、プロセス結果（例えば堆積層の厚さ）が同じ全ての単一時間に出てくるようにすることである。しかし、前に述べたように、汎用コンピューティング・プラットフォームに基づく現在のプロセス制御システムは、大きい複雑なソフトウェア・システムを有し、タイミング精度に対する認識できる制限と、入力の変化に対して迅速に応答し、十分に迅速に反応するのに制限された能力を有する。これらの制限は、最終的に、レシピが繰り返すことができる精度レベルに上限を設け、それは、現在のプロセス装置の歩留まり及びスループットを制限する重大な因子である。結果として、特定のプロセスは、それらが時間どおりに停止できるように意図的に減速される。
これらの改善されたプロセスＩ／Ｏコントローラに伴うこの提示された問題への解決策は、リアルタイム・ベースの遠隔Ｉ／Ｏデバイスにとって重要であると思われるレシピの部分を効果的に代行することである。

メイン・プロセス・コントローラは、（現在の標準であるように）レシピ命令を一度に１つずつ繰返し処理する代わりに、最初にレシピを通してソートし、メイン・コントローラ自体が可能なものを上回るタイミング及び応答精度を要求する部分を定義する。これらの重要なレシピ・ステップは、スクリプトにコンパイルされ、後での実行のために適切なプロセスＩ／Ｏコントローラにロードされる。次に、プロセスＩ／Ｏコントローラは、レシピを繰返し実行し、それ独自のリソースを用いて「重要」とマークされていない部分を実行し、「重要ステップ」の点に到達したときに、スクリプトを開始して、遠隔Ｉ／Ｏユニットの１つを実行し、そのステータスを示すためにスクリプトによって用いられている１つ又はそれ以上の仮想Ｉ／Ｏ変数を通じてスクリプト実行を監視する。
コンパイル相の間、マスター・コントローラは、全ての参照を論理値に、及び、状態を物理又はマップされたＩ／Ｏ参照信号に置き換えることになり、そうでなければ、レシピ・ステップをスクリプト・プログラムに変換することになる。これを達成する１つの方法は、特定のレシピ・ステップ・タイプについて既存のスクリプトが書き込まれる、スクリプト・テンプレートを用いることであり、マスター・コントローラは、この場合、実際のＩ／Ｏ参照及び指定のタイミング並びに閾値を、所定のスクリプト位置に挿入する必要がある。

幾つかの特定の実施形態
本発明は、方法又は方法を実施するように適合された装置として実施することができる。同方法は、ツール・ホスト、スレーブ又はプロセスＩ／Ｏコントローラ、並びに、オペレーティング・プロトコル又はシステムの観点からみることができる。本発明は、方法を実行するために論理が印加されたメディアのような製造品であってもよい。
１つの実施形態は、半導体製造プロセスに対する正確にタイミング合わせされた制御方法である。この方法は、ツール・ホスト及びプロセスＩ／Ｏコントローラを使用する。プロセスＩ／Ｏコントローラは、プロセスチャンバ・モニタへの電気的インターフェースを含み、電気的インターフェースを通じて正確にタイミング合わせされた入力及び出力を制御しサポートする。ツール・ホストは、電気的インターフェースを記号により表すプログラミング環境を含む。この方法は、ツール・ホストにおいて、電気的インターフェースを通じて入力をサンプリングし出力を制御するためのプロセスＩ／Ｏコントローラへの命令を含む制御プログラムを用意することを含む。ツール・ホストからプロセスＩ／Ｏコントローラに制御プログラムがロードされる。プロセスＩ／Ｏコントローラにおいて、制御プログラムを呼び出すコマンドを受け取ると、制御プログラムは、電気的インターフェースを通じて入力をサンプリングし出力を制御する統計的に正確なタイミングを生成するように動作する。入力のサンプリング及び出力の制御は、実時間における目標時間の間の変動分布の９９．９９％範囲の変動が５ミリ秒より小さいか又はそれに等しいときに、統計的に正確なタイミングを有すると考えられる。幾つかの場合、目標時間は、できるだけ早いものとすることができ、コマンドの性能は、５ミリ秒以内であるか又はそれに等しいものとすることができる。他の場合には、目標時間は、入力が特定のレベルに達し次第すぐのものとすることができる。

この方法の１つの態様は、制御プログラムがＪａｖａＳｃｒｉｐｔといった解釈可能プログラミング言語で用意されてもよいことである。解釈可能プログラミング言語の使用によって、コマンド又は他のプログラムを実行する優先度を妨害することなく、制御プログラムをロードすることが容易になる。最初の態様と組み合わされてもよい別の態様は、制御プログラムをロードすることが、他のプロセスＩ／Ｏコントローラ又はツール・ホストから受け取られるかに関係無しに、プロセスＩ／Ｏコントローラによるコマンド処理の優先度を保つロード処理優先度で進むことである。さらに別の態様は、プロセスＩ／Ｏコントローラを、電気的インターフェースを通じた少なくとも幾つかの入力のサンプリング及び出力の制御からオフラインにすることなく、制御プログラムをロードすることに関係する。

少なくとも１つの実施形態においては、入力のサンプリング及び出力の制御は、３ミリ秒よりも小さいか又はそれに等しい、実時間における目標時間の間の変動分布の９９．９９％の範囲で実行されてもよい。目標時間と実時間との間の変動分布の９９．９９％範囲が３ミリ秒よりも小さいか又はそれに等しい状態で実行されてもよい。説明されたモノリシック・コントローラの実施形態は、入力のサンプリング及び出力の制御の正確なタイミングを与えることができ、それにより、目標時間と実時間との間の変動分布の９９．９９％範囲は、１ミリ秒よりも小さいか又はそれに等しい。
作動中に、この方法は、サンプリングされた入力に対応するツール・ホスト仮想デジタル信号を設定し、電気的インターフェースを通じて出力を変化させる、プロセスＩ／Ｏコントローラを含んでもよい。プロセスＩ／Ｏコントローラは、サンプリング及び制御の統計的に正確なタイミングを乱すことなく、これらの仮想デジタル信号を送信する。仮想デジタル信号は、タイムスタンプを含んでもよい。ツール・ホストは、仮想デジタル信号に応答して、プロセスＩ／Ｏコントローラに制御プログラムの動作を停止させるコマンドをプロセスＩ／Ｏコントローラに送信してもよい。
プロセスＩ／Ｏコントローラは、制御プログラムに応答して、統計的に正確なタイミングで制御コマンドを別のプロセスＩ／Ｏコントローラに送信してもよい。ツール・ホストは、レシピにおける制御ステップについてのタイミング公差を受諾し、プロセスＩ／Ｏコントローラにそれらの制御ステップのタイミングを委ねるかどうかを決定するように構成されてもよい。制御ステップのタイミングを委ねることが決定されたときには、制御プログラムが用意され、プロセスＩ／Ｏコントローラにロードされる。

別の実施形態は、中央コントローラと協働するプロセスＩ／Ｏコントローラを用いて、繰返し可能な間隔でプロセス・チャンバにおいて動作するプロセスを制御する方法である。この方法は、動作チャンバの１つ又はそれ以上の態様を監視し制御するプロセスＩ／Ｏコントローラにおいて、中央コントローラから制御コマンドを受け取り、受け取り後に５ミリ秒又はそれ以下の第１の統計的に繰返し可能な短い時間間隔内で制御コマンドを処理することを含む。短い時間間隔は、時間分布の９９．９９％範囲の時間が、その短い時間間隔より短いか又はそれに等しいときに、統計的に繰返し可能であると考えられる。プロセスＩ／Ｏコントローラはまた、制御コマンドの処理における統計的な繰返し可能性を損なうことなく、プロセス・チャンバに結合された１つ又はそれ以上のセンサをサンプリングし、サンプリング・スケジュールの統計的に繰返し可能な公差内でサンプルを与える。公差は、目標時間と実時間との間の変動分布の９９．９９％範囲の変動が公差より小さいか又はそれに等しいときに、統計的に繰返し可能であると考えられる。ハードウェアの実施形態に応じて、第１の統計的に繰返し可能な短い時間間隔は、３ミリ秒又はそれ以下、或いは、１ミリ秒又はそれ以下とすることができる。また、ハードウェアの実施形態に応じて、統計的に繰返し可能な公差は、５ミリ秒、３ミリ秒、或いは、１ミリ秒又はそれ以下とすることができる。

前述の方法を実施するうえで、サンプルのバッファリングは、サンプルに対応するタイムスタンプをバッファリングすることを含んでもよい。プロセスＩ／Ｏコントローラは、制御コマンドの処理の統計的繰返し可能性を損なうか又はサンプリングの統計的繰返し可能性を損なうことなく、少なくとも幾つかのバッファリングされたサンプルを分散させることができる。もう１つの方法として、方法はさらに、制御コマンドの処理の統計的繰返し可能性を損なうか又はサンプリングの統計的繰返し可能性を損なうことなく、プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行することを含んでもよい。これらの命令は、サンプリングの選択された結果に応答することを含んでもよく、応答は、中央コントローラにサンプリングを報告し、応答コマンドを受け取るのに必要な統計的に繰返し可能なフィードバック間隔よりも短い第２の統計的に繰返し可能な短い時間間隔内で起こる。もう１つの方法として、第２の統計的に繰返し可能な短い時間間隔は、第１の統計的に繰返し可能な短い時間間隔の長さの半分よりも小さくてもよい。

この方法はさらに、プロセス・チャンバの作動を監視し制御する態様からプロセスＩ／Ｏコントローラをオフラインにすることなく、命令を受け取り、認識し、プロセスＩ／Ｏコントローラのメモリに動的にローディングすることを含んでもよい。或いは又はそれと組み合わせて、それらのための方法は、制御コマンドの受け取り及び処理の統計的繰返し可能性を損なうか又はサンプリングの統計的繰返し可能性を損なうか或いは動的にロードされた命令の実行の統計的繰返し可能性を損なうことなく、バッファリングされたサンプルの少なくとも幾つかを分散させることを含んでもよい。

方法の別の態様は、制御コマンドの受け取り及び処理の統計的繰返し可能性を損なうか又はサンプリングの統計的繰返し可能性を損なうことなく、プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行してもよいことである。特に、これらの命令は、プロセス・チャンバの作動の少なくとも１つの態様の閉ループ制御を開始することを含んでもよく、開始することは、フィードバック間隔よりも短いか又は第１の統計的に繰返し可能な短い時間間隔の半分よりも短い第２の統計的に繰返し可能な短い時間間隔内で起こる。幾つかの場合には、第２の短い時間間隔は、第１の統計的に繰返し可能な短い時間間隔の長さの１／５よりも短くてもよい。この方法は、プロセス・チャンバの監視し制御する態様からプロセスＩ／Ｏコントローラをオフラインにすることなく、プロセスＩ／Ｏコントローラが命令を受け取り、認識し、プロセスＩ／Ｏコントローラのメモリに動的にロードすることを含んでもよい。プロセスＩ／Ｏコントローラは、統計的繰返し可能性を損なうことなく、バッファリングされたサンプルの少なくとも幾つかを分散させてもよい。
装置として、プロセスＩ／Ｏコントローラは、中央プロセッサと通信するように適合されたポート、メモリ、並びに、ポート及びメモリに結合され、方法及び前述のそれらの態様のいずれかを実行するように適合された論理及びリソースを含んでもよい。

本発明は、上で詳述された好ましい実施形態及び例を参照することによって開示されるが、これらの例は制限する意味ではなく例示となることを意図されている。

本発明の態様が特に有用な環境を示す図である。 性能と、分布としての分散統計を示す図である。 性能と、分布としての分散統計を示す図である。 ツール、センサ及びツール・ホストと通信するための単一型の通信チャネルを用いるプロセスＩ／Ｏコントローラのブロック図である。 複数型の通信チャネルを用いる図である。 プロセスＩ／Ｏコントローラを構築するのに用いることができるソフトウェア及びハードウェア・コンポーネントのブロック図である。 プロセスＩ／Ｏコントローラの物理的アーキテクチャの高レベル・ブロック図である。 ＭＯＤＢＵＳ／ＴＣＰインターフェースを有するＩ／Ｏ及びＣＯＭアーキテクチャのブロック図である。 プロセスＩ／Ｏコントローラをツール・ホストに関連させる高レベル・ブロック図である。

Claims (21)

1. ツール・ホスト及びプロセスＩ／Ｏコントローラを用いる半導体製造プロセスに対する正確にタイミング合わせされた制御方法であって、前記プロセスＩ／Ｏコントローラは、プロセスチャンバ・モニタへの電気的インターフェースを含み、前記電気的インターフェースを通じて正確にタイミング合わせされた入力及び出力を制御しサポートし、前記ツール・ホストは、前記電気的インターフェースを記号により表すプログラミング環境を含み、前記方法は、
   前記ツール・ホストにおいて、前記電気的インターフェースを通じて入力をサンプリングし出力を制御するための前記プロセスＩ／Ｏコントローラへの命令を含む制御プログラムを用意することと、
   前記ツール・ホストから前記プロセスＩ／Ｏコントローラに前記制御プログラムをロードすることと、
   前記プロセスＩ／Ｏコントローラにおいて、前記制御プログラムを呼び出すコマンドを受け取ると、前記制御プログラムが、前記電気的インターフェースを通じて入力をサンプリングし出力を制御する統計的に正確なタイミングを生成するように動作することと、
   を含み、前記入力のサンプリング及び前記出力の制御は、目標時間と実時間との間の変動分布の９９．９９％範囲の変動が５ミリ秒より小さいか又はそれに等しいときに、統計的に正確なタイミングを有すると考えられることを特徴とする方法。
2. 前記制御プログラムをロードすることは、前記プロセスＩ／Ｏコントローラによるコマンド処理の優先度を保つロード処理優先度で進むことを特徴とする請求項１に記載の方法。
3. 前記制御プログラムをロードすることは、さらに、前記プロセスＩ／Ｏコントローラを、前記電気的インターフェースを通じた少なくとも幾つかの入力のサンプリング及び出力の制御からオフラインにすることなく進むことを特徴とする請求項２に記載の方法。
4. 前記入力のサンプリング及び前記出力の制御は、目標時間と実時間との間の変動分布の９９．９９％範囲が３ミリ秒よりも小さいか又はそれに等しい状態で実行されることを特徴とする請求項１に記載の方法。
5. 前記入力のサンプリング及び前記出力の制御は、目標時間と実時間との間の変動分布の９９．９９％範囲が１ミリ秒よりも小さいか又はそれに等しい状態で実行されることを特徴とする請求項１に記載の方法。
6. 前記プロセスＩ／Ｏコントローラは、前記サンプリング及び前記制御の統計的に正確なタイミングを乱すことなく、前記ツール・ホストに、前記電気的インターフェースを通じた前記入力のサンプリング及び前記出力の変化に対応する仮想デジタル信号を送信することをさらに含むことを特徴とする請求項１に記載の方法。
7. 前記仮想デジタル信号はタイムスタンプを含むことを特徴とする請求項６に記載の方法。
8. プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行することが可能な、中央コントローラと協働するプロセスＩ／Ｏコントローラを用いて、繰返し可能な間隔でプロセス・チャンバにおいて動作するプロセスを制御する方法であって、
   前記プロセス・チャンバの作動の１つ又はそれ以上の態様を監視し制御するプロセスＩ／Ｏコントローラにおいて、
   前記中央コントローラから制御コマンドを受け取り、受け取り後に５ミリ秒又はそれ以下の第１の統計的に繰返し可能な短い時間間隔内で前記制御コマンドを処理し、
   前記短い時間間隔は、時間分布の９９．９９％範囲の時間が、前記短い時間間隔より短いか又はそれに等しいときに、統計的に繰返し可能であると考えられ、
   前記制御コマンドの処理における統計的な繰返し可能性を損なうことなく、前記プロセス・チャンバに結合された１つ又はそれ以上のセンサをサンプリングし、サンプリング・スケジュールの統計的に繰返し可能な公差内でサンプルをバッファリングし、
   公差は、目標時間と実時間との間の変動分布の９９．９９％範囲の変動が公差より小さいか又はそれに等しいときに、統計的に繰返し可能であると考えられる
   ことを特徴とする方法。
9. 前記第１の統計的に繰返し可能な短い時間間隔は、３ミリ秒又はそれ以下であることを特徴とする請求項８に記載の方法。
10. 前記第１の統計的に繰返し可能な短い時間間隔は、１ミリ秒又はそれ以下であることを特徴とする請求項８に記載の方法。
11. 前記統計的に繰返し可能な公差は、５ミリ秒又はそれ以下であることを特徴とする請求項８に記載の方法。
12. 前記統計的に繰返し可能な公差は、３ミリ秒又はそれ以下であることを特徴とする請求項８に記載の方法。
13. 前記サンプリングに対応するタイムスタンプをバッファリングすることをさらに含む、請求項８に記載の方法。
14. 前記プロセスＩ／Ｏコントローラは、前記制御コマンドの処理の統計的繰返し可能性を損なうか又は前記サンプリングの統計的繰返し可能性を損なうことなく、バッファリングされたサンプルの少なくとも幾つかを分散させることをさらに含むことを特徴とする請求項８に記載の方法。
15. 前記制御コマンドの処理の統計的繰返し可能性を損なうか又は前記サンプリングの統計的繰返し可能性を損なうことなく、前記プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行することをさらに含み、
    前記命令は、前記サンプリングの選択された結果に応答することを含み、前記応答は、前記中央コントローラに前記サンプリングを報告し、前記中央コントローラから応答コマンドを受け取るのに必要な統計的に繰返し可能なフィードバック間隔よりも短い第２の統計的に繰返し可能な短い時間間隔内で起こることを特徴とする請求項８に記載の方法。
16. 前記制御コマンドの処理の統計的繰返し可能性を損なうか又は前記サンプリングの統計的繰返し可能性を損なうことなく、前記プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行することをさらに含み、
    前記命令は、前記サンプリングの選択された結果に応答することを含み、前記応答は、前記第１の統計的に繰返し可能な短い時間間隔の長さの半分よりも短い第２の統計的に繰返し可能な短い時間間隔内で起こることを特徴とする請求項８に記載の方法。
17. 前記制御コマンドの受け取り及び処理の開始の統計的繰返し可能性を損なうか又はサンプリングの統計的繰返し可能性を損なうことなく、前記プロセスＩ／Ｏコントローラのメモリから動的にロード可能な命令を実行することをさらに含み、
    前記命令は、前記プロセス・チャンバの作動の少なくとも１つの特定の態様の閉ループ制御を開始することを含み、前記開始することは、前記第１の統計的に繰返し可能な短い時間間隔の半分よりも短い第２の統計的に繰返し可能な短い時間間隔内で起こることを特徴とする請求項８に記載の方法。
18. 前記第２の統計的に繰返し可能な短い時間間隔は、前記第１の統計的に繰返し可能な短い時間間隔の長さの１／５よりも短いことを特徴とする請求項１６または１７のいずれかの請求項に記載の方法。
19. 前記プロセスＩ／Ｏコントローラにおいて、前記プロセス・チャンバの作動を監視し制御する態様から前記プロセスＩ／Ｏコントローラをオフラインにすることなく、命令を受け取り、認識し、前記プロセスＩ／Ｏコントローラのメモリに動的にロード可能な命令をロードすることをさらに含むことを特徴とする請求項１６または１７のいずれかの請求項に記載の方法。
20. 前記プロセスＩ／Ｏコントローラは、前記制御コマンドの受け取り及び処理の開始の統計的繰返し可能性を損なうか又は前記サンプリングの統計的繰返し可能性を損なうか或いは前記動的にロード可能な命令を実行する統計的繰返し可能性を損なうことなく、バッファリングされたサンプルの少なくとも幾つかを分散させることをさらに含むことを特徴とする請求項１６または１７のいずれかの請求項に記載の方法。
21. 前記中央コントローラと通信するように適合されたポートと、
    メモリと、
    前記ポート及び前記メモリに結合され、請求項８、１４、１６または１７のいずれかの請求項に記載のプロセスを実行するように適合された論理及びリソースと、
    を含むことを特徴とするプロセスＩ／Ｏコントローラ。

Images